Подписаться
Читать в телеграм
Не ошибается лишь тот, кто ничего не делает. Не бойтесь ошибаться – бойтесь повторять ошибки.
Теодор Рузвельт
Отсутствие backup . Это может звучать банально, но в нашей практике встречались случаи, когда заказчик, к примеру, удалял виртуальную машину, у которой не было бэкапа. Иногда всё заканчивается хорошо – удаётся восстановить все данные с файловой системы VMFS, но, к сожалению, не всегда всё складывается так удачно. Другая проблема может быть связана с отсутствием резервных копий базы данных vCenter. Представьте сложную виртуальную инфраструктуру, например, когда поверх vCenter работает vCloud. Мы сталкивались с ситуациями, когда vCloud необратимо изменяет базу данных vCenter. В этом случае восстановление работоспособности всего решения осуществляется с помощью бэкапа. Поэтому его наличие – правило номер один.
Кроме того, заказчики не обращают внимания на матрицу совместимости версий ПО/«железа» и его прошивок . С помощью VMware Compatibility Guide, представленного на официальном сайте вендора, всегда можно проверить соответствие между «железом», прошивкой, ESX и т.д. Отметим, что компания может не получить вендорской поддержки, если используемое ею решение отсутствует в матрице. В своей практике мы также встречаемся с ситуациями, когда апгрейд прошивки до рекомендуемой версии позволяет решить проблему совместимости.
Третий момент – отсутствие выработанной политики обновления . Например, за год появляется 8 апдейтов ESX 5.5, соответственно, возникает вопрос – устанавливать их или нет? Практика позывает, что выход первой версии ESX, как правило, сопровождается ошибками, которые впоследствии будут устранены. Поэтому логичнее начинать использование продукта после выхода для него первого апдейта или хотя бы патча. Но и здесь есть исключения: к примеру при эксплуатации виртуальной инфраструктуры версии 5.1 можно встретиться с ошибками, которые точно устранены в версии 5.5. Оптимальная политика – использовать не первую версию продукта и регулярно обновляться.
Нельзя забывать и про переподписку ресурсов . Часто бывает так, что в виртуальную среду, изначально рассчитанную на 4–5 виртуальных машин (ВМ) на сервер, по требованию бизнеса добавляют ещё несколько ВМ, не расширяя инфраструктуру физически. Соответственно появляются машины, не обеспеченные аппаратными ресурсами.
Нужно помнить и про существование таких компонентов среды, как VMware vMotion или VMware High Availability, которым тоже требуются определенные ресурсы – в случае сбоя ВМ «поедут» на другие ESX, на которые ресурсов в результате может не хватить. Важно планировать виртуальную среду, опираясь на SLM (Service Level Management) при взаимодействии с бизнесом.
Пятая ошибка возникает из-за различий в конфигурациях между гипервизорами . При проведении аудитов мы сталкивались с ситуациями, когда два ESX видят разное кол-во datastore’ов. В этом случае ВМ, перемещаясь между гипервизорами, не видит всех своих дисковых ресурсов, что приводит к её неработоспособности. Другой пример: часто при изменении конфигурации одного гипервизора изменить конфигурацию другого забывают. Из-за этого поведение ВМ будет меняться, как только она «поедет» на другой ESX. Пока гипервизоров 5 или 10, за ними еще можно уследить, но когда их 100, это становится огромной проблемой. Необходимо использовать специальный VCS-софт (Version Control System – система контроля версий) или не изменять «расширенные настройки» (Advanced Settings) конфигурации.
Причиной проблем также может стать игнорирование ошибок в работе сети, SAN и массивов . Виртуальная среда не изолирована – часто мы анализируем причины «падения» ВМ и обнаруживаем, что им предшествовали сбои в работе SAN и массивов. Ситуация осложняется тем, что SAN, как правило, обслуживает одно подразделение, а виртуальную среду – другое. Соответственно о сбое в SAN специалисты, отвечающие за виртуальную инфраструктуру, узнают только после «падения» ВМ. Решить эту проблему можно настроив мониторинг журнальных файлов. Например, в случае возникновения ошибок SAN появятся множественные оповещения, на которые можно успеть среагировать, потому что сбой не происходит моментально. Кроме того, важно наладить обмен информацией между подразделениями.
Также мы часто сталкиваемся с невключением виртуальной инфраструктуры компании в зону ответственности систем мониторинга . В статье уже упоминалось, насколько важно отслеживать состояние виртуальной инфраструктуры на всех её уровнях. Даже используя простейшие средства можно предотвратить всевозможные проблемы. Например, с помощью приложения для смартфона можно провести мониторинг состояния ESX и доступных ресурсов и предотвратить сбои, связанные с банальной нехваткой места на файловой системе.
Распространенной ситуацией также является отсутствие Scratch Partition – специального раздела, использующегося для хранения логов и другой важной информации при перезагрузке гипервизора. К нам обращались заказчики, у которых ESX работает с флэшки и Scratch Partition отсутствует. Поскольку раздел является необязательным, в случае его отсутствия вышеупомянутая информация хранится на RAM Disk сервера и после перезагрузки очищается. Таким образом, использование Scratch Partition поможет сохранить важную информацию и избежать проблем в дальнейшем (логи, к примеру, помогут установить причину сбоя, и предотвратить его повторение).
Ещё одна ошибка – рассинхронизация времени . Опять же, звучит довольно банально, но рассинхронизация между виртуальной средой, массивами, свитчами и т.д. встречается довольно часто. Нужно стараться избегать этого, чтобы в случае возникновения сбоев верно скоррелировать события в инфраструктуре между собой.
Последний пункт в нашем ТОП 10 – отсутствие обслуживания СУБД vCenter . Её можно наглядно проиллюстрировать с помощью кадров из мультика Pixar: большая птица садится на провод рядом с воробьями и в какой-то момент опускает его. В результате воробьи остаются голыми, а их перья повисают в воздухе. На практике мы часто сталкиваемся с похожей ситуацией. Компании-заказчики начинают работать, установив, например, 5 ESX и один vCenter с Microsoft SQL Server. В процессе роста инфраструктуры при определенном количестве ESX СУБД vCenter перестает справляться с нагрузкой. Чтобы этого избежать, её необходимо своевременно обслуживать: бэкапить, проводить сайзинг (при сильном росте инфраструктуры – использовать другие редакции, или, к примеру, воспользоваться решениями Oracle), регламентные работы по удалению лишних данных и т.д.
«Не ошибается тот, кто ничего не делает». Поэтому бояться нужно не самих ошибок – они неизбежны, а их повторения. В нашей статье мы рассмотрели наиболее часто встречающиеся случаи, но существует и множество других нюансов, которые нужно учитывать. Понимая это, мы советуем начать с аудита виртуальной инфраструктуры. Наши специалисты могут проанализировать конфигурацию среды виртуализации, просмотреть журналы и обратить внимание компаний-заказчиков как на уже существующие, так и на потенциальные упущения, которые могут привести к нарушениям в работе виртуальной среды.
