Итак, я хочу начать использовать свой SAN немного больше, чем раньше, и в то же время воспользоваться преимуществами ESXi.
В настоящее время у меня есть массив блейд-серверов Dell PowerEdge 1955, подключенных к массиву хранения EMC AX4-5 FC с одним корпусом. По сути, я использую SAN как DAS. У меня есть LUN в SAN, которые указывают на определенные физические машины, и эти машины используют LUN для чего угодно (в основном для баз данных и общих ресурсов Samba/NFS, в зависимости от целевого сервера).
У меня есть несколько физических файловых серверов, и на каждом из них есть настройка конфигурации samba для обслуживания соответствующих общих ресурсов. Поскольку я так и не заставил работать RHCS, только один из файловых серверов имеет смонтированные LUN за раз. В случае, если файловый сервер умирает, я вручную ограждаю его (либо отмонтируя и отключая диск, используя утилиту navisphere, либо отключая питание через DRAC), затем использую утилиту navisphere, чтобы вывести представленные LUN на следующем претенденте (после чего запускаю apache и другие демоны). Все вручную, прямо сейчас.
Чувствую себя как Феррис Бьюллер, играющий на кларнете. Никогда не ходил на уроки!
В любом случае, я пытаюсь улучшить. Я хочу установить ESXi на физических хостах, затем создать LUN для хранения двух образов файловых серверов (на случай, если один из них будет поврежден/fubar), один из которых будет активным, другой — резервным. По крайней мере, таким образом я не улучшаю автоматизацию (хотя я скоро напишу скрипт для переключения «активного» сервера), но я чувствую, что добавляю гибкости, плюс я могу использовать хосты ESXi для хранения других виртуальных машин, и оборудование не будет тратиться впустую, как сейчас.
У меня есть вопросы:
1) Насколько глуп мой план?
2) Что касается фактической реализации, следует ли мне создать обычный образ vmdk на LUN или выделить ему «сырой» раздел (если это вообще возможно с ESXi?)
3) Существует ли «хороший» способ использования некластеризованных файловых серверов?
решение1
Ваш план не сумасшедший. Как обычно, есть более чем несколько способов атаковать это в зависимости от того, чего вы пытаетесь достичь и как защитить свои данные.
Во-первых, вы можете представить необработанный LUN виртуальной машине с помощью «Raw Device Mapping». Для этого:
- Предоставьте LUN хосту ESXi (или группе хостов, если вы собираетесь использовать кластеризацию/HA)
- Добавьте диск к своей виртуальной машине, выберите Raw Device Mapping, укажите LUN.
- Повторное сканирование шины SCSI внутри виртуальной машины.
- fdisk, монтируем и добавляем в fstab, как обычный диск.
Преимущества: быстро настраивается, быстро используется, прост, может представлять диск на физическом хосте, если вам в дальнейшем понадобится V2P
Недостаток: вы можете потерять некоторые возможности моментального снимка/отката на базе VMware в зависимости от того, используете ли вы физический или виртуальный режим совместимости.
Альтернативный вариант — создать VMFS на LUN для создания хранилища данных, а затем добавить диск VMDK к виртуальной машине, работающей в этом хранилище данных.
- Плюсы: он дружественный Storage vMotion, если вы когда-нибудь купите лицензию на его использование. Это позволяет производить горячую миграцию дисков VMDK между LUN и даже SAN.
В обоих случаях вы находитесь в одинаковой ситуации риска, если VMware или ваша виртуальная машина уничтожат файловую систему во время сбоя; один из вариантов не намного лучше другого, хотя доступные варианты восстановления будут существенно различаться.
Я не развертываю RDM, если в этом нет необходимости; я обнаружил, что они не дают мне особой гибкости как VMDK (и меня это укусило)ошибкичто делало их непрактичными при выполнении других операций хранения (теперь это исправлено - см. раздел RDM по этой ссылке))
Что касается вашей виртуальной машины, лучшим вариантом для гибкости будет сохранение загрузочного диска вашего файлового сервера в виде VMDK в SAN, чтобы другие хосты могли загрузить его в случае отказа хоста. Используя функционал HA VMware, загрузка вашей виртуальной машины на другом хосте происходит автоматически (виртуальная машина загрузится на втором хосте, как если бы питание было отключено; ожидайте выполнения обычных fsck и магии, чтобы поднять ее, как в случае обычного сервера). Обратите внимание, HA — это лицензированная функция.
Чтобы смягчить последствия сбоя виртуальной машины, вы можете создать легкий клон вашего файлового сервера, содержащий минимум, необходимый для загрузки и запуска SAMBA в настроенном состоянии, и сохранить его на локальном диске каждого хоста, ожидая, пока вы добавите диск с данными из неисправной виртуальной машины и включите ее.
Это может дать вам дополнительные возможности в случае сбоя SAN; в лучшем случае, вашему хранилищу данных потребуется fsck или другой ремонт, но, по крайней мере, вам не придется чинить, перестраивать или настраивать VM поверх. В худшем случае, вы потеряете данные и вам нужно будет вернуться к ленте... но вы и так уже были в таком состоянии.
решение2
Я бы остановился на образах vmdk, просто если вы в будущем перейдете на vmotion, никогда не знаешь, получится ли у вас выделить на это бюджет.
Если ваши машины не кластеризованы, то, насколько я понимаю, лучший способ управлять ими — попытаться распределить нагрузку как можно более равномерно. У меня есть 3 некластеризованных 2950, где нагрузка от самых критических vms составляет максимально 1/3 на каждую. Теоретически я вряд ли потеряю больше одного ящика за раз, так что по крайней мере 2/3 смогут продолжать работать без последствий.
С точки зрения энергопотребления, вероятно, было бы эффективнее загрузить машины как можно ближе к 100%, а остальные машины отключить, но мне кажется, что это все равно, что класть все яйца в одну корзину.
Я бы не назвал себя экспертом в этом деле, это просто моя работа.
решение3
Привет, Мэтт. Существует множество способов разбить решение на части при использовании решения виртуализации. Во-первых, было много тестов, показывающих производительность Raw LUN (RDM) по сравнению с VMDK, и разница обычно оказывается незначительной. Вот что нужно знать о RDM: Только определенные ситуации кластеризации требуют использования RDM (кластеризация MS). RDM имеют ограничение в 2 ТБ, но LVM можно использовать для обхода этого ограничения. RDM «сложнее» отслеживать, чем предоставление LUN для ESXi для использования для VMFS и размещение на нем vmdk. VMDK (как уже упоминалось) имеют несколько приятных преимуществ: svMotion, моментальные снимки (невозможно сделать моментальный снимок pRDM).
Если вы используете Free ESXi, вот как я могу поступить в вашей ситуации. Во-первых, все данные находятся в файлах vmdk на VMFS LUNS. Настройте 2 VM и используйте Heartbeat для аварийного переключения IP и служб. Heartbeat переместит IP службы и может обрабатывать скрипты для размонтирования/монтирования LUN данных, где это уместно. Вы даже можете написать скрипт для VMware Remote CLI, чтобы гарантировать, что «неработающая» VM будет отключена для ограждения. При прямой координации heartbeat между системами риск как доступа к LUN данных, так и запуска тех же служб должен быть крайне низким. Ключевым моментом здесь является обеспечение того, чтобы монтирование/размонтирование LUN данных и запуск/остановка служб обрабатывались Heartbeat, а не обычными механизмами инициализации.
Альтернативный отказ может быть выполнен через систему мониторинга. Когда он обнаруживает неисправный хост, он может использовать VMware Remote CLI для отключения питания (для безопасности) и последующего включения резервной виртуальной машины. В этой ситуации отказ откатывается довольно вручную.
В моей "крошечной" среде я не видел, чтобы VMDK был поврежден. Я также понял, что если у вас больше 2 хостов ESX(i) или дюжина виртуальных машин, вам понадобится vCenter, чтобы отслеживать все. Некоторые из пакетов Essential/Plus не слишком дороги, учитывая преимущества.
решение4
Я думаю, вам следует спросить себя: «Планирую ли я когда-нибудь вернуться к физическим серверам?»
Если ответ «возможно», то, возможно, вам следует придерживаться RDM. ESXi с RDM (я думаю) потребует от вас покупки чего-то для работы вашего оптоволокна (опять же, не уверен на 100% насчет esxi).
У нас было несколько машин, которые я просто быстро переместил с физических серверов на ESX (4.0) с помощью RDM. У меня была смесь машин Linux и Windows (супер просто для обеих платформ). У нас все еще есть несколько работающих устаревших FreeBSD (6.0 и старше) на физических серверах, для которых мы не можем использовать RDM, потому что старое ядро FBSD не поддерживает это. Это было быстро и не потребовало от меня ничего, кроме указания моего LUN и последующей установки инструментов VMWare. Просто до чертиков... без конвертера, без суеты...
Еще один вопрос, который вам следует задать себе: «Какие функции VMWare я хочу использовать?»
В зависимости от вашего ответа на этот вопрос у вас может не быть выбора, кроме VMDK. Если вы используете SAN для снимков и не заботитесь об использовании vmware для этого, например..
Я поделюсь с вами некоторыми заметками о том, с чем мы столкнулись на данный момент. Vmotion одинаково хорошо работает с RDM и VMDK, Storage Vmotion, с другой стороны, работает правильно только с не-RDM, а попытка использовать хранилище Vmotion для перехода с RDM на VMDK отстой, просто используйте конвертер. Большинство дистрибутивов Linux имеют пакет инструментов vmware с открытым исходным кодом, что делает установку инструментов не проблемой. Приложение резервного копирования работает очень хорошо и бесплатно от vmware, но не делает так много всего, как нам бы хотелось. Я настоятельно рекомендую пройти курс от vmware. Тот, который я прошел, длился неделю и стоил каждой копейки. Поддержка VMWare потрясающая. Если вы получаете контракт на поддержку и вам нужно позвонить, они на высшем уровне. Я расстраиваюсь, пытаясь найти кого-то, кто может мне помочь (слишком много меню...), но как только я их получаю, они ВСЕГДА оказывают быструю и надежную поддержку.