Umlyaut
Expert
Expert

Вопрос к "зубрам" про "мигание" СХД...

Доброй ночи всем! Smiley Happy

Пока не добрался сам до испытаний, хочу задать вопрос местным "сертифицированным монстрам" Smiley Happy (может, кто знает ответ сходу).

Каким образом сервер ESXi4 отработает ситуацию, при которой сетевая СХД (являющаяся datastore сервера и содержащая VM-ки, запущенные на данном ESXi4) на небольшой промежуток времени "пропадёт" из сети, а потом "появится" снова??? Получается, что сервер должен САМ(!)

а) восстановить соединение с этим своим (сетевым) datastore

и

б) заново запустить с этого datastore VM-ки (я так понимаю, они по-любому должны погаснуть при исчезновении СХД).

Хватит ли у самого ESXi-сервера своих "мозгов" для обработки подобного эвента, или нужно использовать дополнительные меры (скрипты, тулзы, etc.)???

Также интересует вариант, если у нас будет не одиночный (отдельный) ESXi4, а HA cluster из них - что можно сделать в таком случае? Подозреваю, что падение VM на первой ноде может спровоцировать её старт на второй (в таком случае если таймаут перед запуском VM на второй ноде будет больше интервала "невидимости" СХД, то нас должен волновать только пункт а) - чтобы вторая нода перед запуском этой VM уже имела в рабочем состоянии datastore/СХД с ней).

P.S. Расшифровываю ситуацию - если в качестве бюджетной СХД без единой точки отказа использовать HA cluster на тех же OpenFiler`ах, то при выходе из строя Primary node этого кластера как раз и будет наблюдаться "сетевое затмение" СХД до перехода Secondary node в активный режим. Ровно та же проблема возникнет, если в качестве СХД использовать MSFC с DAS.

0 Kudos
27 Replies
mb78
Enthusiast
Enthusiast

После недоступности LUN на СХД DS4700. Да - ВМ "остались" "запущенными" - но жесткие диски в данных ВМ были недоступны на запись. Некоторые ВМ наглухо "зависли". ВМ под ОС Linux (SLES) - жили с файловыми сист. ReadOnly/ - подводя итог случившемуся - лучшебы ВМ оказались выключенными.

0 Kudos
m0ps
Enthusiast
Enthusiast

А Вы уроните сторадж ещё разок - если VM-ки опять поднимутся сами, значит не мистика... Smiley Happy

</div>

это типа должно быть смешно? ?:|

best regards, m0ps

best regards, m0ps
0 Kudos
m0ps
Enthusiast
Enthusiast

После недоступности LUN на СХД DS4700. Да - ВМ "остались" "запущенными" - но жесткие диски в данных ВМ были недоступны на запись. Некоторые ВМ наглухо "зависли". ВМ под ОС Linux (SLES) - жили с файловыми сист. ReadOnly/ - подводя итог случившемуся - лучшебы ВМ оказались выключенными.

</div>у VMware HA есть функция, позволяющая перезапускать зависшие VM (VM Monitoring называется). видимо у вас она выключена.

best regards, m0ps

best regards, m0ps
mb78
Enthusiast
Enthusiast

Да вы правы. Данная опция выключена. Очевидно эта тема для отдельного топика. Но при включении данной опции под довольно высокой нагрузкой (СХД и CPU ESX) - несколько "ложных" срабатываний т.е. перезагрузка ВМ. В настоящее время нет возможности заняться этим вопросом. т.е. установить разумные критерии для VM Monitoring. В таком случае могу только подтвердить что при временной недоступности СХД ВМ остались во "включенном" состоянии. Правда недоступность выражалась в неправильном срабатывании драйвера failover ESX ( доступ к СХД пропал при изменении preffered patch).

0 Kudos
Umlyaut
Expert
Expert

<div class="jive-quote">

А Вы уроните сторадж ещё разок - если VM-ки опять поднимутся сами, значит не мистика... Smiley Happy

</div>

это типа должно быть смешно? ?:|

Извините, если это Вас задело. Smiley Sad

Просто ответ №1 в данной ветке как раз содержал упоминание об умышленном отцеплянии стораджа. Да и сам я не дурак попробовать разные технические решения на предмет крашеустойчивости, устаривая этот самый "краш" в натуре. Ес-с-но, не на "боевой" системе (или на боевой, но в нерабочее время, с подстраховкой и по поводам, не предполагающим тотальных невосстановимых "жертв и разрушений").

Посему моя реплика подразумевала тот же modus operandi с Вашей стороны. Ещё раз извините...

0 Kudos
michigun
VMware Employee
VMware Employee

в общем я попробова на домашнем стенде.

Погасил службу iSCSI target. Прождал полчаса - виртуалка с него отображалась живой в консоли ESX, и сами LUN тоже.

rescan для чистоты эксперимента не делал. Спустя полчаса надоеле ждать.

Вывод - мой тестовый стенд не подошел для данного тестирования, вопрос остается открытым.

--

-- http://www.vm4.ru/p/vsphere-book.html
0 Kudos
Umlyaut
Expert
Expert

в общем я попробова на домашнем стенде.

Погасил службу iSCSI target. Прождал полчаса - виртуалка с него отображалась живой в консоли ESX, и сами LUN тоже.

rescan для чистоты эксперимента не делал. Спустя полчаса надоеле ждать.

Вывод - мой тестовый стенд не подошел для данного тестирования, вопрос остается открытым.

--

Кстати, а у Вас standalone ESX или HA cluster?

0 Kudos
evgenyk
Enthusiast
Enthusiast

Если кому-то еще актуально что будет.

При отключении СХД (iscsi) ESX пытается взять следующий путь в списке к луну на котором лежат данные, так пока пути не закончатся. Когда пути закончатся будет фриз. Это значит что пинг до машин будет ходить, но по факту ничего работать не будет. Т.е. например RDP на windows систему открыть будет нельзя.

Далее если вы успеете включить систему хранения до того как ESX объявит storage мертвым то виртуальные машины сделают unfreez и там уже включиться логика операционной системы внутри виртуальных машин - линукс например переведет файловую систему в read only, ибо он подумает что диск умер или умерает, через это писать на него нельзя. Если не успеете, то получите кучу условно включенных виртуальных машин.

Как-то так.

Evgeny Kovalskiy CCNP, VCP, EMCSA IT Infrastructure Architect
0 Kudos