<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Комментарии к записи: Системы NetApp и их работа с бесперебойниками (UPS)</title>
	<atom:link href="http://blog.aboutnetapp.ru/archives/590/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.aboutnetapp.ru/archives/590</link>
	<description>Системы хранения данных как предмет разговора</description>
	<pubDate>Wed, 07 Apr 2021 12:07:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>Автор: Korj</title>
		<link>http://blog.aboutnetapp.ru/archives/590#comment-404</link>
		<dc:creator>Korj</dc:creator>
		<pubDate>Mon, 26 Apr 2010 09:48:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/?p=590#comment-404</guid>
		<description>Хм. В очередной раз вижу, что best practices NetApp нужно читать очень вдумчиво, а в сетевой части - вообще игнорировать от греха подальше...
В современной инфраструктуре датацентра/серверной, с большой вероятностью никакого отдельного маршрутизатора (router) между подсетями СХД и ??БП не будет, а будет L3-коммутация на том же коммутаторе, что и L2.

Предлагаю изложить в следующей редакции: ;)
Учитывая это, следует устроить сеть управления таким образом, чтобы всё сетевое оборудование на пути от UPS до контроллера NetApp было подключено к UPS, и в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.

Собственно такая рекомендация и так записана в документации к APC Network Shutdown, насколько я помню.


Кстати, а какие действия будут производиться при потере контакта с UPS? Вышеупомянутый APC NS достаточно гибко позволяет себя настроить, и при этом достаточно интеллектуально обрабатывает возникающие внештатные ситуации - например можно настроить выключение в случае, если после получения сигнала о переходе на батарею была потеряна связь с ??БП, но игнорировать потерю связи в случае, если работаем от сети.</description>
		<content:encoded><![CDATA[<p>Хм. В очередной раз вижу, что best practices NetApp нужно читать очень вдумчиво, а в сетевой части - вообще игнорировать от греха подальше&#8230;<br />
В современной инфраструктуре датацентра/серверной, с большой вероятностью никакого отдельного маршрутизатора (router) между подсетями СХД и ??БП не будет, а будет L3-коммутация на том же коммутаторе, что и L2.</p>
<p>Предлагаю изложить в следующей редакции: ;)<br />
Учитывая это, следует устроить сеть управления таким образом, чтобы всё сетевое оборудование на пути от UPS до контроллера NetApp было подключено к UPS, и в случае отказа питания, контроллер NetApp не потерял связь с UPS и мог получать данные о их состоянии.</p>
<p>Собственно такая рекомендация и так записана в документации к APC Network Shutdown, насколько я помню.</p>
<p>Кстати, а какие действия будут производиться при потере контакта с UPS? Вышеупомянутый APC NS достаточно гибко позволяет себя настроить, и при этом достаточно интеллектуально обрабатывает возникающие внештатные ситуации - например можно настроить выключение в случае, если после получения сигнала о переходе на батарею была потеряна связь с ??БП, но игнорировать потерю связи в случае, если работаем от сети.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/590#comment-403</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Mon, 26 Apr 2010 09:29:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/?p=590#comment-403</guid>
		<description>Так уж написано в документации.
Подозреваю, что причина в первую очередь в стремлении минимизировать вовлеченную в процесс сетевую инфраструктуру, чтобы не получить ситуацию, когда подсеть управления UPS в результате отключения питания отвалилась оттого, что обесточился роутер, обеспечивающий передачу между подсетями.</description>
		<content:encoded><![CDATA[<p>Так уж написано в документации.<br />
Подозреваю, что причина в первую очередь в стремлении минимизировать вовлеченную в процесс сетевую инфраструктуру, чтобы не получить ситуацию, когда подсеть управления UPS в результате отключения питания отвалилась оттого, что обесточился роутер, обеспечивающий передачу между подсетями.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Korj</title>
		<link>http://blog.aboutnetapp.ru/archives/590#comment-402</link>
		<dc:creator>Korj</dc:creator>
		<pubDate>Mon, 26 Apr 2010 09:05:36 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/?p=590#comment-402</guid>
		<description>"Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились _в той же IP-подсети_, что и контроллер NetApp"
Можете пояснить причину такой рекомендации? Какое отношение IP подсеть имеет к аварийному завершению?</description>
		<content:encoded><![CDATA[<p>&#8220;Учитывая это следует устройть сеть управления таким образом, чтобы UPS находились _в той же IP-подсети_, что и контроллер NetApp&#8221;<br />
Можете пояснить причину такой рекомендации? Какое отношение IP подсеть имеет к аварийному завершению?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/590#comment-401</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Mon, 26 Apr 2010 06:16:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/?p=590#comment-401</guid>
		<description>Это не "по Фрейду", что бы вы под этим ни понимали, это просто пальцы пишут грамматически правильно, несмотря на все маркетологические изыски в области трейдмарков. Поправил.</description>
		<content:encoded><![CDATA[<p>Это не &#8220;по Фрейду&#8221;, что бы вы под этим ни понимали, это просто пальцы пишут грамматически правильно, несмотря на все маркетологические изыски в области трейдмарков. Поправил.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Andrew Ivanov</title>
		<link>http://blog.aboutnetapp.ru/archives/590#comment-400</link>
		<dc:creator>Andrew Ivanov</dc:creator>
		<pubDate>Mon, 26 Apr 2010 05:59:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/?p=590#comment-400</guid>
		<description>Вот только по Фрейду оговорка получилась - не Silicon, а просто Silcon. :)</description>
		<content:encoded><![CDATA[<p>Вот только по Фрейду оговорка получилась - не Silicon, а просто Silcon. :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
