Vmware heartbeat что это
Обновлено: 06.07.2024
Как мы рассказывали в статье «Отказоустойчивость Как и по чем» существует 3 типа отказоустойчивости. В рамках терминологий VMWare и последовательности нашей предыдущей статьи:
- VMware Fault Tolerance
- VMware High availability
- VMware Site Recovery Manager
VMware Fault Tolerance (FT) – функционал, который позволяет в случае недоступности основной машины мгновенно переключить работу на ее копию, которая держится в состоянии горячего резерва. По сути – это реплика виртуальной машины, размещенная на другом ESXi сервере и находящаяся во включенном состоянии. Плюсом этого решения является минимальное время переключения между основной и резервной машиной. Очевидным минусом – высокое потребление ресурсов, поскольку копия занимает столько же ресурсов, сколько и основная машина. На машину с включенным FT накладывается ряд ограничений, в том числе использование снапшотов, подключение различных устройств (virtual usb & floppy, Hot-plug CPU and RAM) и прочие. Использование FT должно быть целесообразно и оправданно.
VMware High Availability (HA) –основной, по мнению автора, функционал для обеспечения отказоустойчивости виртуальной среды VMware. Принцип работы заключается в том, что при катастрофическом сбое, который определяется отказом сервера ESXi или зависанием виртуального сервера, виртуальная машина стартует на другом максимально подходящем хосте ESXi. «Зависание» виртуальной машины обнаруживается с помощью службы VM Monitoring, которая собирает информацию о Heartbeat виртуальной машины посылаемые VMWare Tools. Для работы HA нужно чтобы и виртуальные машины кластера хранились на доступном для всех его хостов хранилище. Это может быть как аппаратная СХД так и программное решение, например virtual SAN.
Для предотвращения перегрузки хостов кластера может использоваться механизм Distributed Resource Scheduler. DRS – инструмент для автоматического размещения виртуальных машин на хостах с учетом равномерной нагрузки на ресурсы каждого хоста. С помощью vMotion DRS перемещает виртуальные машины между хостами «на ходу» без потери доступности виртуального сервера. В VMware vSphere 6 появилась возможность мигрировать машины между датацентрами, которые обслуживаются различными VCenter. (VMware vCenter Server – Программное обеспечение для управления инфраструктурой VMware из единой точки: в том числе организация отказоустойчивых кластеров. ПО доступно как в виде установочного пакета, так и в виде aplience). Также увеличена допустимая задержка в RTT канале до 100мс, что позволяет виртуальным машинам выполнять «трансконтинентальные» миграции обеспечивая в штатном режиме (то есть незаметно для пользователей) возможности переноса виртуальных машин из зон стихийных бедствий или других проблемных геообластей.
Управление продуктом происходит черед консоль VSphere Client, которая я при установке SRM расширяется дополнительным функционалом с помощью плагина.
Принцип работы SRM базируется на репликации блоков данных дисковых массивов выполняющейся средствами ПО систем хранения данных. SRM управляет процессами обеспечения резервирования и восстановления данных через адаптеры репликации (SRA, Storage Replication Adapter), которые поставляются производителем СХД. В качестве хранилища для recovery site может выступать, в том числе, и NAS-система.
Решение может быть использовано в различных сценариях: автоматическое восстановление сайта на резервной площадке, миграция инфраструктуры на новую площадку, снятие излишней нагрузки с основного сайта, развертывание тестовых сред.
Новые подробности о продукте VMware vCenter Heartbeat.
Не так давно на VM Guru была новость об анонсе продукта VMware vCenter Heartbeat. Сегодня мы расскажем о нем поподробнее, поскольку NDA уже перестало действовать (блоггеры открыли большинство «секретов»).
Итак, основная цель продукта vCenter Heartbeat – постоянная доступность сервера vCenter (VirtualCenter), которой раньше пытались достигнуть сторонними средствами, например, Microsoft Cluster Services. Такая ситуация не устраивала клиентов VMware, которые, во-первых, хотели законченное решение по постоянной доступности от одного вендора, а, во-вторых, защиту на всех уровнях vCenter (WAN failure, компоненты VirtualCenter). Как оказалось, таких клиентов достаточно много – большинство используют физические серверы vCenter (60%) – поэтому технология Fault Tolerance не выход. У большинства (60%) vCenter и его БД – разделены по разным машинам. Кроме того, использование средства катастрофоустойчивости (VMware vCenter Site Recovery Manager) также требует постоянной доступности на случай катастроф.
В итоге, VMware заключила OEM-соглашение с компанией Neverfail, по которому ее технология высокой доступности и application management framework (AMF) будут использоваться в vCenter Heartbeat.
По сути, vCenter Heartbeat – это инструмент для создания кластера высокой доступности для vCenter (active-passive), между нодами которого создается канал для обмена хартбитами и репликации данных SQL-сервера. Пока известно, что Heartbeat будет выпущен только для Microsoft SQL Server. Пассивный vCenter защищается специальным фильтром от видимости из публичной сети.
vCenter Heartbeat обеспечивает защиту сервера управления на 4-х уровнях: «железа», сбоев ОС, сетевых проблем и неполадок в ПО vCenter Server (SQL Server, License Server, Update Manager и т.п.). Что еще важно – vCenter Heartbeat отслеживает производительность vCenter, и на основе метрик можно определить критические показатели, превышения которых приведут к переключению vCenter Server. vCenter Heartbeat умеет делать как автоматический Failover при сбоях, так и автоматический Failback с синхронизацией с активным узлом.
В качестве нод кластера vCenter Heartbeat поддерживаются все типы конфигураций: V2V, P2V, P2P.
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Настройки VM Monitoring, рис. 7.10.
Суть этого механизма HA - в том, что он отслеживает наличие сигналов пульса (heartbeat) от VMware tools. Предполагается, что отсутствие этих сигналов означает зависание VMware tools вследствие зависания гостевой ОС.
Если сигналы пульса (heartbeat) отсутствуют в течение «Failure interval» секунд, а с момента старта ВМ прошло не менее «Minimum uptime» секунд, то ВМ перезагружается. Однако ее перезагрузят не больше «Maximum per-VM resets» раз за время «Maximum resets time window».
Этот механизм, по сути, является аналогом так называемого watchdog-таймера, реализованного в BIOS многих серверов.
- VM monitoring status - если этот флажок не стоит, то данный механизм не работает;
- Default Cluster settings - настройки работы механизма. На рисунке приведен вариант «Custom». Если одноименный флажок не стоит, то мы можем выбрать один из трех вариантов по умолчанию;
- Virtual Machine Settings - указание предыдущих настроек индивидуально на уровне каждой ВМ.
Иногда возможны ситуации, что сигналы пульса (heartbeat) от VMware tools пропали, но ВМ работает. Чтобы не перезагружать работающую ВМ в такой ситуации, компонент VM Monitoring отслеживает еще и активность ввода-вывода ВМ. Если сигналы пульса (heartbeat) пропали и не возобновились вновь в течение
Рис. 7.10. VM Monitoring
«Failure interval» секунд, то смотрится на активность работы этой ВМ с диском и сетью за последние 120 секунд. Если активности не было, ВМ перезагружается.
Мне этот механизм представляется слишком грубым, чтобы с ходу начать его использовать. Однако если у вас есть регулярно зависающие виртуальные машины и перезапуск как решение проблемы вас устраивает - только для этих ВМ функция VM Monitoring подойдет отлично.
Обратите внимание, что в версии 4.1 VMware реализовала API для сторонних поставщиков кластерных решений под названием Application Monitoring. Суть этого механизма - в том, что сторонние агенты, установленные в гостевые ОС, могут отслеживать статус приложений и взаимодействовать с сервером vCenter и агентами HA для инициации перезагрузки ВМ при проблемах в работе приложения. На момент написания единственным известным мне приложением, реализующим Application Monitoring для VMware HA, является Symantec ApplicationHA.
Так как настройки такого рода дополнений в полной мере зависят от используемого стороннего средства, здесь они не рассматриваются.
$cluster.ExtensionData.RetrieveDasAdvancedRuntimeInfo()
Здесь мы видим поле (объект) HeartbeatDatastoreInfo.
Набираем последовательно
Теперь нам даже нет необходимости исследовать данный объект, по виду вывода мы предполагаем что это объект API. Значит используем командлет Get-VIObjectByVIView. Поскольку в данном случае мы получаем не дочерний объект, а производим конвертацию объекта, то не забываем использовать знак конвейера.
$cluster.ExtensionData.RetrieveDasAdvancedRuntimeInfo().HeartbeatDatastoreInfo.Datastore | Get-VIObjectByVIView
Теперь посмотрим как создать командлет на get-view.
Мы можем воспользоваться конструкцией
Либо присвоить нашей переменной $cluster новый объект
$cluster = get-view -ViewType ClusterComputeResource -filter @Используем второй вариант.
Теперь выполним последовательно
Вывод идентичный.
Итак, мы изучили и закрепили использование при работе с PowerCLI методов.
Посмотрим как еще можно получить информацию о HeartbeatDatastore.
Теперь мы можем одинаково успешно работать с API двумя способами, но в данный момент в переменной $cluster у нас объект get-view, да и не забываем про рекомендацию, поэтому вводим
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
- Отказоустойчивость (Fault Tolerance, FT) — способность системы к дальнейшей работе после выхода из строя какого-либо её элемента.
- Кластер — группа серверов (вычислительных единиц), объединенных каналами связи.
- Отказоустойчивый кластер (Fault Tolerant Cluster, FTC) — кластер, отказ сервера в котором не приводит к полной неработоспособности всего кластера. Задачи вышедшей из строя машины распределяются между одной или несколькими оставшимися нодами в автоматическом режиме.
- Непрерывная доступность (Continuous Availability, CA) — пользователь может в любой момент воспользоваться сервисом, перерывов в предоставлении не происходит. Сколько времени прошло с момента отказа узла не имеет значения.
- Высокая доступность (High Availability, HA) — в случае выхода из строя узла пользователь какое-то время не будет получать услугу, однако восстановление системы произойдёт автоматически; время простоя минимизируется.
- КНД — кластер непрерывной доступности, CA-кластер.
- КВД — кластер высокой доступности, HA-кластер.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Аппаратный способ представляет собой “раздвоенный” сервер: все компоненты дублированы, а вычисления выполняются одновременно и независимо. За синхронность отвечает узел, который в числе прочего сверяет результаты с половинок. В случае несоответствия выполняется поиск причины и попытка коррекции ошибки. Если ошибка не корректируется, то неисправный модуль отключается.
На Хабре недавно была статья на тему аппаратных CA-серверов. Описываемый в материале производитель гарантирует, что годовое время простоя не более 32 секунд. Так вот, для того чтобы добиться таких результатов, надо приобрести оборудование. Российский партнёр компании Stratus сообщил, что стоимость CA-сервера с двумя процессорами на каждый синхронизированный модуль составляет порядка $160 000 в зависимости от комплектации. Итого на кластер потребуется $1 600 000.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
- На физическом хосте должен быть процессор:
- Intel архитектуры Sandy Bridge (или новее). Avoton не поддерживается.
- AMD Bulldozer (или новее).
Лицензирование vSphere привязано к физическим процессорам. Цена начинается с $1750 за лицензию + $550 за годовую подписку и техподдержку. Также для автоматизации управления кластером требуется приобрести VMware vCenter Server, который стоит от $8000. Поскольку для обеспечения непрерывной доступности используется схема 2N, для того чтобы работали 10 нод с виртуальными машинами, нужно дополнительно приобрести 10 дублирующих серверов и лицензии к ним. Итого стоимость программной части кластера составит 2 *(10 +10 )*(1750 +550 )+8000 =$100 000.
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
- Вычислительный. К нему относятся ноды, на которых непосредственно запущены виртуальные машины
- Кластер хранилища. Тут находятся диски, которые используются нодами вычислительного подкластера.
- Heartbeat версии 1.х в связке с DRBD;
- Pacemaker;
- VMware vSphere;
- Proxmox VE;
- XenServer;
- Openstack;
- oVirt;
- Red Hat Enterprise Virtualization;
- Windows Server Failover Clustering в связке с серверной ролью “Hyper-V”;
- VMmanager Cloud.
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
- Происходит поиск узла кластера с наименьшим количеством виртуальных машин.
- Выполняется запрос хватает ли свободной оперативной памяти для размещения текущей ВМ в списке.
- Если памяти для распределяемой машины достаточно, то VMmanager отдаёт команду на создание виртуальной машины на этом узле.
- Если памяти не хватает, то выполняется поиск на серверах, которые несут на себе большее количество виртуальных машин.
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
VMmanager Cloud поддерживает следующие типы хранилищ: файловая система, LVM, Network LVM, iSCSI и Ceph . В контексте КВД используются последние три.
При использовании вечной лицензии стоимость программной части кластера из десяти “боевых” узлов и одного резервного составит €3520 или $3865 на сегодняшний день (лицензия стоит €320 за ноду независимо от количества процессоров на ней). В лицензию входит год бесплатных обновлений, а со второго года они будут предоставляться в рамках пакета обновлений стоимостью €880 в год за весь кластер.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
- Возможность предоставления виртуальных машин на KVM;
- Наличие интеграции с Ceph;
- Наличие интеграции с биллингом подходящим для предоставления имеющихся услуг;
- Доступная стоимость лицензий;
- Наличие поддержки производителя.
Отличительные черты кластера:
- Передача данных основана на технологии Ethernet и построена на оборудовании Cisco.
- За маршрутизацию отвечает Cisco ASR9001; в кластере используется порядка 50000 IPv6 адресов.
- Скорость линка между вычислительными нодами и коммутаторами 10 Гбит/с.
- Между коммутаторами и нодами хранилища скорость обмена данными 20 Гбит/с, используется агрегирование двух каналов по 10 Гбит/с.
- Между стойками с нодами хранилища есть отдельный 20-гигабитный линк, используемый для репликации.
- В узлах хранилища установлены SAS-диски в связке с SSD-накопителями.
- Тип хранилища — Ceph.
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
- Большой опыт работы с продуктами ISPsystem.
- Наличие интеграции с BILLmanager по умолчанию.
- Отличное качество техподдержки продуктов.
- Поддержка Ceph.
- Передача данных основана на сети Infiniband со скоростью соединения 56 Гбит/с;
- Infiniband-сеть построена на оборудовании Mellanox;
- В узлах хранилища установлены SSD-носители;
- Используемый тип хранилища — Ceph.
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно :)
Читайте также: