понедельник, 28 июня 2010 г.

VMFS resignaturing

Из переписки:

Михаил, приветствую!
У меня такая проблема, может посоветуете чего...
Вкратце, что есть:
Два ЦОД, репликация данных посредством СХД
Настроен boot from SAN на обеих площадках.
При переезде с одной площадки на другую, ESX4 грузится, но теряет все виртуалки из инвентори, которые на нем должны быть, как следствие, не поднимется VC, и все остальное. Тома ESX-ы РЦОД видит как snap-xxxxxxx, т.к. изменился LUN ID.
По Вашей книге необходимо проводить действия вручную через VC client. Но это нам не подходит из-за большого кол-ва ESX(40) и виртуальных машин(200).
Подскажите, пожалуйста, как сделать автоматическое поднятие всего ЦОД на РЦОД?
В какую сторону копать?
Что я ответил:
Приветствую.
вообще, решать именно вашу задачу призван продукт VMware site recovery manager.
кроме разного полезного прочего он и описанную проблему решает сам.
правда, он стоит денег.
если без него, то единственное, что приходит на ум — это поразбираться, решается ли данная проблема скриптами.
Кроме скриптов я тут вариантов не вижу.
Решается ли это на скриптах (локальных в Service Console, vSphere CLi или PowerCLI) я просто не помню — не приходилось такую задачу решать.
Почему так: потому что в ESX(i) 4 поменялся механизм работы с такими ЛУНами. Какими “такими” и откуда вообще проблема берется, напомню.
1) Вкратце: когда создается VMFS на каком-то LUN, кроме прочего в метаданные записывается номер этого LUN. Если этот номер меняется, то ESX(i) не дает обратиться к такому LUN.
Почему? Потому что такая ситуация обычна для репликации\снапшотов СХД — мы реплицируем LUN с номером X на LUN с номером Y — и в VMFS на Y прописано, что номер LUN=X. И если на LUN Y начать что-то писать, процесс репликации нарушиться (ну или записать нам не дадут — в любом случае это не дело). Вот ESX(i) обучен не обращаться к LUN’ам с таким расхождением, т.к. это является характерным признаком реплики LUN.
Подробнее про это и другое про VMFS можно посмотреть тут — Устройство VMFS-раздела.
2) Если надо таки дать доступ к такому LUN (например см. вот тут — Траблшутинг ESXi, и без всяких репликаций такая задача может встать), то
В третьей версии VMware Infrustructure надо было сделать так:
1. Закладка «Configuration»
2. Advanced Settings
3. В разделе LVM, изменить LVM.EnableResignature на 1 (по умолчанию 0)
4. В Storage Adapters сделайте "Rescan«
5. Хранилище VMFS должно появится (под другим именем)
6. Установить EnableResignature обратно в 0
7. Вручную зарегистрировать ВМ на хостах.
3) А в четверке уже не так — заходим в мастер добавления хранилища, видим там наш LUN, и

мастер предложит нам добавить этот VMFS без форматирования и удаления данных.
Суть поста вот в чем: мне сообщили, что старый, от тройки, способ все равно продолжает работать, правда, из командной строки:
Приветствую.
Мне помогла такая вещь:
esxcfg-advcfg -s 0 /LVM/DisallowSnapshotLUN

решение работает, резервный ЦОД запустился!!
+ дописать в vmx uuid.action = «keep»
А я, пока искал инфу для этого поста, обнаружил что писал таки про способ сделать это в четверке из CLI:

Вот в комментариях подсказали правильную ссылочку с информацией поподробнее: http:/kb.vmware.com/kb/1011387.

thx Александру Черкашину.

4 комментария:

  1. Вроде вот так надо?
    http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1011387&sliceId=1&docTypeID=DT_KB_1_1&dialogID=86428505&stateId=0%200%20101849662

    ОтветитьУдалить
  2. в этой статье описано более подробно то, что указано на слайде.

    спасибо.

    ОтветитьУдалить
  3. Mikhail nisaglashus po povadu, pochemu repliciravani LUN viden kak snapshot, po sute ESX obshiaetsia s lunami ispozua NNA, esli bit po proshe eto UUID LUN-a i tak kak u kajdogo luna eto unikalno poetomu i vidno shto v metatate vidno UUDI ot drugova LUN-a a shas u LUN-drugoi, popovadu, LUN ID bili problemi v 3 prosta propadal dostup k LUN-u , a v chetviorke s LUN-amu gavarit po NNA

    ОтветитьУдалить
  4. ок, спасибо.
    т.е. один и тот же LUN теперь может разным серверам быть презентован под разным номером?

    тем не менее принципиальной сути это не меняет.

    ОтветитьУдалить