Хорошо, поэтому я хочу начать использовать свой 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) Есть ли «хороший» способ использовать некластеризованные файловые серверы?
Ваш план не безумный. Как обычно, существует несколько способов атаковать это в зависимости от того, чего вы пытаетесь достичь и как защитить свои данные.
Во-первых, вы можете представить необработанный LUN виртуальной машине с помощью «Raw Device Mapping». Сделать это:
Плюс: быстрая установка, быстрая в использовании, простая, может представлять диск физическому хосту, если вам понадобится V2P в дальнейшем.
Оборотная сторона: вы можете потерять некоторые параметры снимка / отката на основе VMware, в зависимости от того, используете ли вы физический или виртуальный режим совместимости.
Альтернативный вариант - создать VMFS на LUN для создания хранилища данных, а затем добавить диск VMDK к виртуальной машине, находящейся в этом хранилище данных.
В обоих случаях вы подвергаетесь аналогичному риску, если VMware или ваша виртуальная машина съест файловую систему во время сбоя; один не намного лучше другого, хотя доступные варианты восстановления будут совершенно другими.
Я не развертываю RDM без необходимости; Я обнаружил, что они не дают мне большой гибкости в качестве VMDK (и меня укусили ошибки что сделало их непрактичными при выполнении других операций с хранилищем (так как исправлено - см. раздел RDM в этой ссылке))
Что касается вашей виртуальной машины, лучший вариант гибкости - сохранить загрузочный диск файлового сервера как VMDK в сети SAN, чтобы другие хосты могли загружать его в случае сбоя хоста. Используя функциональность VMware HA, загрузка вашей виртуальной машины на другом хосте выполняется автоматически (виртуальная машина загружается на втором хосте, как если бы было отключено питание; ожидайте выполнения обычных fsck и волшебства, чтобы поднять его, как в случае с обычным сервером. ). Обратите внимание: HA - это лицензионная функция.
Чтобы предотвратить сбой виртуальной машины, вы можете создать легкий клон своего файлового сервера, содержащий минимум, необходимый для загрузки и запустить SAMBA в настроенном состоянии, и сохранить его на локальном диске каждого хоста, ожидая, что вы добавите диск с данными из вышла из строя виртуальная машина и включите ее.
Это может дать вам или не дать вам дополнительные возможности в случае сбоя SAN; В лучшем случае ваше хранилище данных потребует fsck или другого ремонта, но, по крайней мере, вам не нужно исправлять, перестраивать или настраивать виртуальную машину поверх. В худшем случае вы потеряли данные и вам нужно вернуться на ленту ... но вы все равно уже были в этом состоянии.
Мэтт, вы знаете, что я не использую VMware, но я всегда использовал "RAW" с Xen. С небольшим количеством загруженных виртуальных машин я сомневаюсь, что вы заметите большую разницу в производительности. Но когда вы начнете получать все больше и больше гостей, если все эти гости находятся в одной файловой системе, вы столкнетесь с проблемами глубины очереди. Это особенно верно для хранилищ с поддержкой NFS. Дело не в том, что у сервера NFS есть проблемы, но у большинства реализаций клиента NFS - отстой.
Я не знаю, как хорошо синхронизировать vmdks, если вам нужна избыточность (отказ системы). Но если вы используете блочные устройства, у вас все еще есть возможность использовать DRBD для репликации только виртуальных машин, которые вы хотите / должны реплицировать.
Привет, Мэтт. Есть много способов разделить решение, когда вы используете решение для виртуализации. Во-первых, было проведено множество тестов, показывающих производительность Raw LUN (RDM) по сравнению с VMDK, и разница, как правило, незначительна. Некоторые вещи, о которых следует знать о RDM: Только определенные ситуации кластеризации требуют использования RDM (кластеризация MS). У RDM есть ограничение в 2 ТБ, но LVM можно использовать для обхода этого ограничения. За RDM «сложнее» следить, чем давать LUN ESXi для использования для VMFS и помещать на него vmdk. VMDK (как уже упоминалось) имеют некоторые приятные преимущества: svMotion, Snapshots (не может делать снимки pRDM).
Если вы используете Free ESXi, вот как я могу поступить в вашей ситуации. Прежде всего, все данные находятся в файлах vmdk на LUNS VMFS. Установите 2 виртуальных машины и используйте Heartbeat для переключения IP и служб при отказе. Heartbeat сместит IP-адрес службы и может обрабатывать сценарии для отключения / подключения LUN данных, где это необходимо. Вы даже можете написать сценарий VMware Remote CLI, чтобы гарантировать, что «неработающая» виртуальная машина будет отключена для ограждения. При прямой координации пульса между системами риск доступа к луне данных / запуска одних и тех же служб должен быть чрезвычайно низким. Ключевым моментом здесь является обеспечение того, чтобы монтирование / размонтирование LUN данных и запуск / завершение работы служб обрабатывались Heartbeat, а не обычными механизмами инициализации.
Альтернативное переключение при отказе может быть выполнено через систему мониторинга. Когда он обнаруживает неработающий хост, он может использовать VMware Remote CLI для отключения питания (в целях безопасности), а затем включения резервного виртуального компьютера. В этой ситуации возвращение происходит вручную.
В моей "крошечной" среде я не видел, чтобы VMDK был поврежден. Я также пришел к выводу, что если у вас более двух хостов ESX (i) или десятка виртуальных машин, вам понадобится vCenter, чтобы отслеживать все. Некоторые пакеты Essential / Plus не слишком дороги, учитывая преимущества.
Я бы придерживался изображений vmdk, на всякий случай, если вы перейдете к использованию vmotion в будущем, вы никогда не знаете, что у вас может быть бюджет для этого.
Если ваши машины не кластеризованы, то, насколько мне известно, лучший способ управлять ими - это попытаться распределить нагрузку настолько равномерно, насколько это возможно. У меня есть 3 некластеризованных 2950, где нагрузка от наиболее важных виртуальных машин составляет по возможности 1/3 на каждую. Теоретически я вряд ли потеряю более одного ящика одновременно, поэтому по крайней мере 2/3 смогут продолжать работу без изменений.
С точки зрения мощности, вероятно, было бы более эффективно загрузить машины как можно ближе к 100% и отключить другие машины, но мне кажется, что складывать все яйца в одну корзину.
Я бы не стал называть себя экспертом в этом деле, я просто делаю это.
Думаю, вам следует спросить себя: «Планирую ли я когда-нибудь вернуться к физическим серверам?»
Если ответ - возможно, тогда, возможно, вам стоит придерживаться 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 - это потрясающе .. Если вы получаете контракт на поддержку и вам нужно звонить, они на высшем уровне ... Я расстраиваюсь, пытаясь найти кого-то, кто может мне помочь (для многих меню ... ), но как только я их получаю, они ВСЕГДА приходят с быстрой и надежной поддержкой.