Настройка fault tolerance vmware
You can turn on vSphere Fault Tolerance through the vSphere Client .
When Fault Tolerance is turned on, vCenter Server resets the virtual machine's memory limit and sets the memory reservation to the memory size of the virtual machine. While Fault Tolerance remains turned on, you cannot change the memory reservation, size, limit, number of vCPUs, or shares. You also cannot add or remove disks for the VM. When Fault Tolerance is turned off, any parameters that were changed are not reverted to their original values.
Connect vSphere Client to vCenter Server using an account with cluster administrator permissions.
Prerequisites
The option to turn on Fault Tolerance is unavailable (dimmed) if any of these conditions apply:
- The virtual machine resides on a host that does not have a license for the feature.
- The virtual machine resides on a host that is in maintenance mode or standby mode.
- The virtual machine is disconnected or orphaned (its .vmx file cannot be accessed).
- The user does not have permission to turn the feature on.
Results
The specified virtual machine is designated as a Primary VM, and a Secondary VM is established on another host. The Primary VM is now fault tolerant.
Note: The VM datastores and memory are replicated during the FT Turn On process. This can take several minutes depending on the size of the replicated data. The VM state does not appear as protected until replication is complete.
В данной статье попробую на базе своей виртуальной лаборатории попробовать описать основные вопросы установки и настройка технологии Fault Tolerance (FT) в среде VMWare vCenter. Также постараюсь описать типовые проблемы, возникающие при использовании VMWare Fault Tolerance, а также методики их лечения. Надеюсь эта статья поможет всем тем, кто хотел бы разобраться и понять технологию VMWare Fault Tolerance.
Что же такое VMware Fault Tolerance? Это технология VMWare, предназначенная для защиты виртуальные машины с помощью кластеров непрерывной доступности. Т.е. при отказе хоста (сервера ESXi) с основной (Primary) рабочей копией виртуальной машины защищенная виртуальная машина мгновенно переключается на «вторичную» (Secondary) или «теневую» копию, работающую на другом сервере ESX. Для машин, защищенных при помощи VMWare Fault Tolerance, происходит постоянное (в реальном времени) копирование всего состояния памяти и процессорных инструкций с основной копии на «теневую». Т.е. при сбое основного хоста ESX, пользователи не должны даже заметить процесс переключения на второй узел. Именно этим Fault Tolerance отличается от High Availability, ведь в случае HA при отказе физического сервера виртуальные машины будут перезапущены на других узлах, при этом будет даунтайм, в течении которого будут запускаться операционные системы и приложения. С Fault Tolerance даунтайма не будет.
Сразу стоит отметить, что для использования VMware FT необходимо выполнить ряд требования:
Опишу свой тестовый стенд:
· 2 одинаковых сервера HP с установленным ESXi 4.1.
· 6 сетевых карт на сервер
· 1 тестовая однопроцессорная виртуальная машины W2K3R2 x64bit.
ВключаемFault Tolerance
Для того, чтобы включить VMWare Fault Tolerance для защиты определенной машины, необходимо правой кнопкой мыши щелкнуть по ней и в появившемся меню выбрать пункт «Turn on Fault Tolerance».
Это все! Вроде бы все просто, однако достаточно часто появляется ряд ошибок, попробуем в них разобраться.
Типовыеошибки VMWare Fault Tolerance
1. Отсутствует FT VMkernel
Для работы технологии FT требуется специальный сетевой интерфейс, который будет использоваться для копирования данных и логов с Primary виртуальной машины на Secondary. Для этих целей необходимо создать отдельный порт VMkernel, либо же задействовать существующий. В моем, случае, для этих целей я задействую выделенную сеть для vMotion, т.к. операции vMotion не будут выполнятся очень часто, забивая трафиком данный интерфейс.
В настройке интерфейса VMkernel ставим галочку напротив опции «Fault Tolerance logging»
2. Недостаточно ресурсов для HA
Ошибка следующая: «Insufficient resources to satisfy configured failover level for HA»
Для работы FT требуется работа технологии VMware High Availability. В моей среде у меня есть всего два хоста ESXi, включёнными в кластер HA, в результате в резерве у меня есть всего один сервер. Для работы FT такое решение не подходит, поэтому нужно либо добавить дополнительный хост в кластер HA, либо настроить HA на резервирование % от ресурсов, задав, например, 5%.
3. Тонкие (Thin) диски необходимо переконвертировать в обычные (thick)
Ошибка: «The disk block of the virtual machine’s disks have not been fully provisioned on the file system. This is needed to support features like Fault Tolerance»
Fault Tolerance не работает с тонкими дисками, поэтому необходимо преобразовать их в «толстые» (thick).
Отключите тестовую виртуальную машины. Откройте хранилище с ней (Browse datastore), правой кнопкой щелкните по vmdk диску и в меню выберите “Inflate”
Технология FT – это мощное решение по защите ваших бизнес-критичных приложений. Ради эксперимента я попробовал запустить пинг на машину, защищенную при помощи Fault Tolerance, и отключил первичный сервер ESXi, в результате ни одного пинга не было потеряно! Однако через интерфейс vmkernel (FT log) прошло большое количество трафика на скорости 33Мбит/сек. Поэтому, при использовании, Fault Tolerance необходимо заранее спрогнозировать и обеспечить высокую пропускную способность на этом сегменте сети.
В данной статье попробую на базе своей виртуальной лаборатории попробовать описать основные вопросы установки и настройка технологии Fault Tolerance (FT) в среде VMWare vCenter. Также постараюсь описать типовые проблемы, возникающие при использовании VMWare Fault Tolerance, а также методики их лечения. Надеюсь эта статья поможет всем тем, кто хотел бы разобраться и понять технологию VMWare Fault Tolerance.
Что же такое VMware Fault Tolerance? Это технология VMWare, предназначенная для защиты виртуальные машины с помощью кластеров непрерывной доступности. Т.е. при отказе хоста (сервера ESXi) с основной (Primary) рабочей копией виртуальной машины защищенная виртуальная машина мгновенно переключается на «вторичную» (Secondary) или «теневую» копию, работающую на другом сервере ESX. Для машин, защищенных при помощи VMWare Fault Tolerance, происходит постоянное (в реальном времени) копирование всего состояния памяти и процессорных инструкций с основной копии на «теневую». Т.е. при сбое основного хоста ESXI, пользователи не должны даже заметить процесс переключения на второй узел. Именно этим Fault Tolerance отличается от High Availability, ведь в случае HA при отказе физического сервера виртуальные машины будут перезапущены на других узлах, при этом будет даунтайм, в течении которого будут запускаться операционные системы и приложения. С Fault Tolerance даунтайма не будет.
Сразу стоит отметить, что для использования VMware FT необходимо выполнить ряд требования:
Опишу свой тестовый стенд:
- 2 одинаковых сервера HP с установленным ESXi 5.1.
- 6 сетевых карт на сервер
- 1 тестовая однопроцессорная виртуальная машины W2K3R2 x64bit.
Procedure
- In the vSphere Client , browse to the virtual machine for which you want to turn on Fault Tolerance.
- Right-click the virtual machine and select Fault Tolerance > Turn On Fault Tolerance .
- Click Yes .
- Select a datastore on which to place the Secondary VM configuration files. Then click Next .
- Select a host on which to place the Secondary VM. Then click Next .
- Review your selections and then click Finish .
Типовые ошибки VMWare Fault Tolerance
1. Отсутствует FT VMkernel
Причина:
Для работы технологии FT требуется специальный сетевой интерфейс, который будет использоваться для копирования данных и логов с Primary виртуальной машины на Secondary. Для этих целей необходимо создать отдельный порт VMkernel, либо же задействовать существующий. В моем, случае, для этих целей я задействую выделенную сеть для vMotion, т.к. операции vMotion не будут выполнятся очень часто, забивая трафиком данный интерфейс.
Решение:
В настройке интерфейса VMkernel ставим галочку напротив опции «Fault Tolerance logging»
Установка и настройка VMware Fault Tolerance-04
2. Недостаточно ресурсов для HA
Установка и настройка VMware Fault Tolerance-05
Причина:
Для работы FT требуется работа технологии VMware High Availability. В моей среде у меня есть всего два хоста ESXi, включёнными в кластер HA, в результате в резерве у меня есть всего один сервер. Для работы FT такое решение не подходит, поэтому нужно либо добавить дополнительный хост в кластер HA, либо настроить HA на резервирование % от ресурсов, задав, например, 5%.
Решение:
Установка и настройка VMware Fault Tolerance-06
3. Тонкие (Thin) диски необходимо переконвертировать в обычные (thick)
Установка и настройка VMware Fault Tolerance-07
Ошибка: «The disk block of the virtual machine’s disks have not been fully provisioned on the file system. This is needed to support features like Fault Tolerance»
Причина:
Fault Tolerance не работает с тонкими дисками, поэтому необходимо преобразовать их в «толстые» (thick).
Решение:
Отключите тестовую виртуальную машины. Откройте хранилище с ней (Browse datastore), правой кнопкой щелкните по vmdk диску и в меню выберите “Inflate”
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении 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-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно :)
Подходы к обеспечению отказоустойчивости
Включаем Fault Tolerance
Для того, чтобы включить VMWare Fault Tolerance для защиты определенной машины, необходимо правой кнопкой мыши щелкнуть по ней и в появившемся меню выбрать пункт «Turn on Fault Tolerance».
Установка и настройка VMware Fault Tolerance-01
Соглашаемся с действием.
Установка и настройка VMware Fault Tolerance-02
Это все! Вроде бы все просто, однако достаточно часто появляется ряд ошибок, попробуем в них разобраться.
VM Monitoring
VM Monitoring, как уже говорилось выше, - служба мгновенной перезагрузки виртуальной машины при потери тактовых импульсов от утилиты VMTools, установленной на эту ВМ.
VM Monitoring довольно долго были в статусе experimental, но сегодня они уже доступны для промышленного использования. Однако VMware пока не спешит их ставить по умолчанию - неудивительно, ведь пользователи не раз сталкивались с ситуацией, когда VM Monitoring на ранних этапах своего развития давал сбой и попусту перезагружал виртуальные машины.
Здесь задача VMware состоит в техническом усовершенствовании возможностей VM Monitoring, а также постепенное завоевание доверия пользователей.VMware Fault Tolerance (FT)
VMware Fault Tolerance (FT) – средство непрерывной доступности виртуальных машин, позволяющее поддерживать резервную работающую копию виртуальной машины на другом сервере, которая мгновенно переключает на себя нагрузку в случае отказа основной машины.
Она позволяет защитить виртуальные машины с помощью кластеров непрерывной доступности, позволяющих в случае отказа хоста с основной виртуальной машиной мгновенно переключиться на ее «теневую» работающую копию на другом сервере ESXI.
Иными словами, данная функция создает такую же ВМ, но назначенную параметром Backup VM, которая мгновенно становится Primary VM после прекращения приема пакета тактовых импульсов, отсылающихся пакетом VMTools виртуальной машины, сервером.
У такой технологии есть как свои положительные стороны, так и отрицательные.
Данная технология позволяет максимизировать отказоустойчивость отдельных ВМ, что, конечно же, обрадует заказчика.
Но представьте, если создать каждой ВМ такую теневую машину.
Теневая ВМ это такая же ВМ с такими же характеристиками, что и основная, только готовая в любой момент времени встать на ее место. При увеличении в два раза ВМ, также увеличатся и потребляемые ресурсы При включении данной технологии будут наложены существенные ограничения на отношения ВМ и хостов, систему хранения и сетевые параметры данной ВМ.
У ВМ как Primary, так и Secondary есть несколько ограничений:
Эксперты выделяют несколько правил, при которых технология FT будет применяться с наибольшим коэффициентом полезного действия:Поместите ISO-образы, которые используют FT-машины на общее хранилище, чтобы primary и secondary ВМ могли иметь доступ к этим данным;
Отключите power management в BIOS хостов ESXi. Если они войдут в power-saving mode, то может не хватить ресурсов CPU на Secondary VM на выполнение задач синхронно с первичной ВМ;
На саму ВМ с включенным FT также будут наложены ограничения. Основные из них:
VMware FT рекомендован к использованию к следующим ВМ:
Следует отметить, что данная служба (FT) недоступна пользователям, купившим пакет Essentials и Essentials PlusПодробнее о сценариях лицензирования »» VMware ESXI
Distributed Resource Scheduler (DRS)
Distributed Resource Scheduler (DRS) – технология, выравнивающая нагрузку серверов ESXI. Данная функция необходима, если в системе образуется сервер с максимальными нагрузками на нем. DRS перебрасывает ресурсы на более низко используемые серверы, таким образом, усредняя коэффициент использования всех серверов.
В следующей версии VSphere Client’а будет доступна также технология DRS for Storage.VMware Site Recovery Manager (SRM)
VMware Site Recovery Manager (SRM) – продукт автоматизирующий процессы аварийного восстановления, создания и тестирования планов восстановления после катастроф.
Данный продукт предлагает передовые возможности управления аварийным восстановлением, тестирования без прерывания работы и автоматизированного аварийного переключения.
VMware vCenter Site Recovery Manager поддерживает управление аварийным переключением на резервные инфраструктуры, а также между двумя инфраструктурами с активными рабочими нагрузками.
Более того, возможно восстановление нескольких инфраструктур из одной общей резервной системы.
Site Recovery Manager также помогает обеспечить плановое аварийное переключение ЦОД, например при их переносе.Управление аварийным восстановлением:
Обнаружение и визуализация виртуальных машин, защищенных репликацией хранилища, с помощью средств интеграции, сертифицированных поставщиками систем хранения;
Хранение, просмотр и экспорт результатов тестирования, а также запуск аварийного переключения из VMware vCenter Server;
Управление доступом к планам восстановления с помощью детализированных элементов управления доступом на основе ролей;
Тестирование без прерывания работы:Средства создания снимков обеспечивают тестирование восстановления без потери реплицированных данных;
Автоматизированное аварийное переключение:Автоматизация назначения реплицированных хранилищ данных для восстановления с помощью адаптеров, созданных ведущими поставщиками систем хранения для своих платформ репликации;
Преимущества перехода на виртуальную среду
При виртуализации есть несколько серьезных преимуществ, по сравнению с физическим аналогом построения инфраструктуры:
Эксплуатационная гибкостьС помощью виртуализации мы добьемся оперативного реагирования на изменения рынка благодаря динамическому управлению ресурсами, ускоренной инициализации серверов и улучшенного развертывания настольных компьютеров и приложений.
Увеличение отдачи от существующих ресурсов
Возможность объединения общих ресурсов инфраструктуры в пулы и уход от устаревшей модели «один сервер — одно приложение» с помощью консолидации серверов.
Софтверная поддержка
В случае виртуализации ВМ используют ресурсы серверов, на которых они находятся.
Но сама идея виртуализации в том, что на ВМ, например не стоят ЦПУ от компании Intel или AMD, виртуализация поддерживает серверы с разными конфигурациями, а, следовательно, на ВМ на данный момент идет большинство ОС и почти весь поддерживаемый софт этими ОС.
Следовательно, на одних и тех же по характеристикам серверах, возможно, развертывать совершенно независимые друг от друга, и разные по характеристикам ВМ, также и наоборот, серверы с разными характеристиками будут поддерживать один кластер, в котором будут находиться несколько ВМ.Планирование
С помощью удобного клиента управления всей структурой vSphere администратор сможет полностью отслеживать процессы, происходящие с серверами, а также при внедрении дальнейшего оборудования, это поможет гораздо упростить и сделать более прозрачной всю структуру виртуальных систем.
Сокращение расходов
Виртуализация позволяет уменьшать число физических серверов по сравнению с числом растущих виртуальных машин, что позволит сократить расходы на оборудование, энергопотребление, а также персонал, который будет все это обслуживать.
Отказоустойчивость
При внедрении виртуализации, благодаря технологиям VMware, а именно: HA FT DRS и т.д., возможно не только сохранить свой уровень отказоустойчивости до консолидирования ВМ, но и повысить его.
Ниже описаны технологии обеспечения надежности виртуальной системы, а также пути их внедрения.
На ранних этапах консолидирования виртуальных технологий, будет сохранен тот же уровень надежности, но в дальнейшим при достаточно большой инфраструктуре серверного оборудования, данная инфраструктура, основанная на физическом решении, будет постепенно терять надежность с увеличением оборудования, в то время как виртуальная будет его всегда удерживать на определенном уровне.Итак, мы рассмотрели 5 параметров, повышающих отказоустойчивость системы до максимума.
Такие параметры, как HA, FT и DRS являются возможностями платформы, наличие которых будет зависеть от комплектации купленного пакета VMware.
VM Monitoring присутствует во всех версиях платформ, а SRM является отдельным полноценным продуктом компании VMWare, который поставляется также с vCenter Server.
Для более полного представления о том, как их совмещать и где использовать, заказчику следует предварительно проконсультироваться со специалистами, для того, чтобы они исследовали все его характеристики серверного оборудования, и дали более полную оценку консолидации виртуализации в данном проекте.VMware High Availability (HA)
VMware High Availability (HA) – функция высокой доступности.
Возможности VMware HA позволяют повысить отказоустойчивость виртуальной инфраструктуры и сделать непрерывным бизнес компании.
Суть возможностей VMware HA заключается в перезапуске виртуальной машины отказавшего сервера VMware ESXI с общего хранилища (собственно, сам VMware HA), а также рестарте зависшей виртуальной машины на сервере при потере сигнала от VMware Tools (VM Monitoring).Данная функция, несомненно, повышает отказоустойчивость, однако для нее существует ряд ограничений, а имeнно:
Виртуальных машин на хост с числом хостов VMware ESXI 8 и менее для vSphere 4.0 Update 1 - максимально 160;
Для крупных компаний такие числа могут быть недостаточными, так что эта функция полезна для малого и среднего бизнеса, однако, стоит заметить, что компания VMware объявила о своих намерениях в ближайшем будущем эти показатели повысить. Сейчас в кластере HA может быть только 5 primary хостов ESXI, чего явно недостаточно для создания катастрофоустойчивого решения на уровне possible failure domain.
Кроме того, на данный момент нет прозрачного механизма назначения хостов как primary или secondary, что тоже вызывает иногда проблемы. В этом плане компания VMware уже прилагает усилия, чтобы сделать такие кластеры VMware HA, которые будут переживать неограниченное число отказов хостов VMware ESXI.Другими словами VMware High Availability - средство отказоустойчивости виртуальных машин, позволяющее в случае отказа физического хост-сервера автоматически перезапустить его виртуальные машины с общего хранилища
Читайте также: