Заходим в первое меню и активируем Boot from SAN (enable)
Заходим в меню первой карты.Видим картинку:
При загрузке сервера в момент инициализации карт нажимаем Alt-E (согласно подсказки). Попадаем в BIOS Emulex карты. Обе карты настраиваются одинаково.
У раздела, с которого будет бутиться ОС, должен быть самый малый LUN ID. Лучше всего LUN 1 (LUN 0 зарезервирован самим SAN стораджем).
Необходимо по стандартной процедуре выделить место (виртуальный диск) для инсталляции бокса на SAN. Настройку нужно провести ДО настройки BIOS Emulex адаптеров.
Создание тома на SAN
Замечено, что данная настройка иногда может самопроизвольно сбрасываться на блейдах при переносе профайла. Поэтому, если при попытке загрузки бокса наблюдается "красный экран" Illegal opcode или сообщение о невозможности загрузиться, в первую очередь необходимо проверять порядок загрузки
При загрузке сервера жмем F9 и попадаем в настройки BIOS. Заходим в Boot Controller order и выставляем первыми двумя устройствами Emulex карты. Это ОЧЕНЬ важная операция, т.к. иначе работать не будет! Я потратил день, пока сообразил, почему OS ставится, сторадж видится, с rescue грузится, но загрузчик (grub) крешится
Но вернемся к нашей частной задаче. Нам необходимо настроить железо так, чтобы RHEL (а речь пойдет, разумеется, о RedHat Linux, как Enterprise решении) мог загрузиться с SAN. Т.е. как минимум root и boot разделы должны быть на внешнем сторадже. Еще важный момент - к стораджу имеется более одного пути, т.е. мы еще и будем использовать multipath (нам же надежность нужна!). В моем случае имеется 8 путей (4 порта EVA и два порта со стороны blade, всего восемь)
Таким образом, в случае проблем с hardware блейда для рестарта сервера достаточно перенести профайл на другой блейд и загрузить его! Т.е. с точки зрения ОС и приложений - произойдет сброс по питанию, но перенастраивать ничего не нужно. Ну чем не кластер?
Т.е. "легким движением руки" мы можем переместить сервер с одного блейда на другой, сохранив полностью окружение!
Использование flex-10 значительно облегчает жизнь админу вообще и данную задачу в частности. Дело в том, что сетевые низкоуровневые настройки проводятся через интерфейс flex-10. Причем, что немаловажно, во-первых, настройки каждлого бокса "собраны" в специальный профайл, который можно легко и быстро присвоить (assign) любому боксу в enclosure, а, во-вторых, такие важные вещи как MAC адрес сетевых карт и WWPN FC адаптеров можно сделать виртуальными и хранить в профайле!
Имеем enclosure с установленными HP ProLiant BL465c G7 (blade), сетевая инфраструктура блейда обеспечивается модулями Flex-10. В блейде установлены FC адаптеры Emulex. Все это добро подключено к Gigabit Ethernet свичам по меди и Brocade свичам по оптике. В качестве стораджа используется SAN HP EVA.
Итак, немного об окружении (HW environment):
Ок, что же мы можем предпринять? У нас есть SAN, который мы и можем использовать вместо локальных дисков! Сразу появляется (в моем окружении, о котором немного ниже) масса плюсов. Сервер (как логическая единица) становится не привязанным к физическому боксу!
И дело не только в аварии. Штатная операция по апгрейду (смене блейдов) выливается в массу затраченного времени, связанного с инсталляцией нового сервера. перенастройкой на него приложений, проверке всего и т.д. Идеально было бы просто переставить диски из старого сервера в новый, но так поступить нельзя по ряду причин (например, важная причина: старые диски уже отработали пару лет и неизвестно, сколько они проработают еще)
Конечно, можно (и нужно) ставить "запасной" (standby) сервер. Вот только для его активации нужно время - перенастроить database, перенстроить приложения (а их очень немало).
Но что делать, если отдельный бокс (blade) вдруг поломается? Техника HP, конечно, весьма надежная, но, в моей практике был случай, когда блейд через почти два года аптайма повис и управлять им было невозможно до тех пор, пока его физически не вытащили из гнезда и не поставили на место. Все бы ничего, но до датацентра из самой ближней точки полтора часа на машине. Даунтайм совершенно неприемлемый.
В Enterprise системах надежность и минимизация времени простоя ставятся во главу угла. Кластерные системы это. конечно. замечательно, но в некоторых случаях использование кластеров невозможно. Это могут быть как софтверные ограничения, так и политика компании. Например, наши ДБА отказались от использования кластеров Oracle по причине некоторых ограничений в используемых приложениях (не совсем корректная работа с ДБ в режиме кластера).
RHEL 5 SAN boot: подготовка HP ProLiant BL465c G7 к загрузке с SAN » Системный Администратор
Комментариев нет:
Отправить комментарий