Расчет кластера HA

Как рассчитать количество слотов на один хост.

Если приложению выделить на 30% меньше ЦПУ, то в критические моменты оно и будет притормаживать на эти самые 30%. Если же мы выделим на 30% меньше оперативной памяти, чем требуется приложению, то свопа и связанного с ним снижения производительности не избежать. И речь тут может идти о существенном снижении производительности, либо об отказе в работе приложения.

Перед прочтением этой статьи мы рекомендуем ознакомиться с последовательностью создания кластера VMware High Availability (HA).

Для того чтобы понять, сколько слотов будет зарезервировано на один хост при использовании кластера HA, вначале необходимо выписать максимальные характеристики машин (ВМ1 имеет параметры 1Гб памяти и 2ГГц процессора, ВМ2 – 3Гб памяти и 500МГц процессора, максимальные характеристики ВМ – 3Гб памяти и 2ГГц процессора (это и будут параметры одного слота)) и минимальные характеристики хостов (Хост1 имеет параметры 12Гб памяти и 10ГГц процессора, Хост2 – 16Гб памяти и 6ГГц процессора, минимальные характеристики Хостов – 12Гб памяти и 6ГГц процессора (это и будут параметры серверов)). За основу деления по слотам мы берем оперативная память (см. информационную вставку).

После этого делим характеристики хоста на характеристики ВМ (12Гб/3Гб = 4). Все серверы в кластере будут вмещать в себя по 4 слота независимо, самый ли это слабый сервер или самый мощный.

Как считается Failover Capacity для одинаковых и разных узлов.

Как уже рассказывалось ранее, Failover Capacity для одинаковых узлов высчитывается достаточно просто. Для этого нам необходимо знать, сколько у нас хостов, ВМ и сколько слотов на хост. Из количества хостов вычитаем количество ВМ, деленное на среднее количество слотов на узел.

В случае же, когда у нас узлы с разным количеством слотов, мы используем пример, описанный в самом начале: берем наименьшие параметры хостов и применяем их ко всем хостам. Уравниваем количество слотов по наименьшему значению. Самые мощные хосты для HA по количеству слотов будут равны самым слабым. Поскольку все хосты были приведены к одному наименьшему количеству слотов, дальше определяем Failover Capacity как для одинаковых хостов.

В общем мы имеем проблему, а если пойти дальше, то дилемму. Проблема заключается в следующем: раз маломощные хосты так плохо влияют на кластер, надо что-то с ними решать. А дилемма – включать ли это хосты в общий кластер или организовать еще один кластер из самых слабых узлов.

Мы провели некоторый анализ, результаты которого вылились в файл fcap-4-common-and-separate-has.zip. Благодаря этому замечательному Excel документу, мы можем определиться, использовать один кластер или поделить наши узлы на несколько частей. Рассмотрены случаи для трех групп хостов и для двух групп хостов.

Мы условно делим все наши хосты по трем группам: маломощные, средние, мощные. Указываем характеристики хостов (измеряемые в слотах), указываем количество таких хостов и получаем рекомендацию, как лучше организовать кластер. Дальше мы опишем, что мы имели в виду под названием столбцов. Но, повторимся, достаточно указать 6 параметров и решение готово. Смотрите, пользуйте, критикуйте. Описание столбцов для справки ниже.

Что мы собираемся делать

В .xls файле мы сравниваем параметры Failover Capacity в случае объединения всех узлов ESX в один общий кластер и в случае организации нескольких кластеров, объединяя узлы с общими характеристиками. В этом файле нам нужно поменять 6 значений: количество слотов в ESX-хосте группы и количество хостов в группе. В документе представлены 2 варианта: хосты делятся на три, либо на две группы.

Приведем простой пример для трех разных групп:
У нас имеется 2 мощных сервера, вмещающих по 10 слотов, 3 средних сервера по 8 слотов и 3 слабых сервера по 3 слота. В случае если мы создадим один общий кластер из этих серверов, мы сможем разместить в нем всего 21 ВМ (Failover Capacity падает до 0).

В то же время, создав 3 отдельных кластера, мы сможем разместить уже 28 ВМ, что на 33%  больше.

Но это, когда сервера значительно отличаются (отношение между хостами достигает 70%). Попробуем уменьшить отношение и возьмем следующие значения:
У нас имеется 2 мощных сервера, вмещающих по 10 слотов каждый, 3 средних сервера по 8 слотов и 3 слабых сервера, в каждый из которых влезает по 5 слотов. В этом случае, если мы создадим один общий кластер, мы сможем создать 35 ВМ, когда HA перестанет быть полезным (Failover Capacity упадет до 0). В том же случае, если мы создадим 3 разных кластера, на всех хостах будет работать только 31 ВМ. Конечно по сравнению с первым вариантом, три кластера смогут поднимать на 3 ВМ больше. Но зато благодаря приближению результатов поддержки хостами слотов, общий кластер сможет поднимать на 14 ВМ больше. Теперь экономия в 13% будет при использовании одного кластера HA.

Перечень параметров из файла .xls и их описание

При расчетах в файле .xlsбыло взято 2 варианта: 3 (основной) и 2 различных группы узлов с разными параметрами; все расчеты производятся для одних и тех же по параметрам виртуальных машин (расчет слотов)

Хосты А, B, C – узлы с одинаковыми характеристиками выделены в три группы. Основной и единственной характеристикой узла является количество его слотов;

Количество слотов на хост – количество слотов, зарезервированное на один хост

Количество хостов – число узлов ESX, входящих в соответствующую группу;

Слотов в группе – количество слотов на всех хостах группы (Кол-во слотов на хост x Кол-во хостов);

Всего слотов – сумма всех слотов по всем трем группам (А, B, C);

Соотношение параметров хостов – процентное соотношение параметров хостов с меньшими параметрами слотов на узел к хосту с большими параметрами слотов на узел;

Кол-во ВМ – общее количество ВМ, работающих в кластере (кластерах). Мы сравниваем объединение в один кластер и разделение на три кластера для различного количества ВМ;

FC с общим HA – расчет Failover Capacity при объединении хостов всех трех типов в один кластер HA;

FCa+FCb+FCc – расчет Failover Capacity при создании каждой группе хостов (A, B, C) отдельного кластера HA;

Количество машин A (B, C) в кластере 1 (2, 3) – расчет примерного справедливо-равномерного распределения машин по кластерам;

FCa, FCb, FCc – расчет Failover Capacity для каждого из трех кластеров;

Преимущество – разница между Failover Capacity при создании общего кластера и Failover Capacity при создании каждой группе отдельного кластера. По сути, это и есть определяющее значение, какой кластер для какого случая лучше создавать;

Если значение положительное, более рационально создать общий кластер;
Если значение отрицательное, лучше создать отдельные кластеры каждой группе хостов;
Если значение равно нулю, оба варианта подходят (но, думаю, в таком случае лучше создать общий HA кластер, по крайней мере, проще управлять);

Значения в таблице:
Количество машин в общем кластере – максимальное число ВМ, которые могут быть помещены на общий HA-кластер, чтобы он все еще был защищен (последнее значение, когда Failover Capacity больше нуля);

Количество машин в 3-х кластерах – максимальное число ВМ, которые могут быть помещены на три кластера, чтобы они все еще были защищены (последнее значение, когда все три Failover Capacity больше нуля);

Вывод – показывается архитектура, которая будет более правильным, исходя из расчетов;

Преимущество – показывается процентное соотношение выигрыша при использовании рекомендуемой архитектуры;

Выводы по организации HA кластеров.

Вариантов может быть безграничное множество, у каждого может возникнуть ситуация, которую сложно предсказать, но в основном следует придерживаться следующего:

  • Если параметры и производительность хостов ESX сильно разнятся, следует разделить их на группы по характеристикам и создать отдельные кластеры;
  • Чем больше похожи по характеристикам все ESX (количество слотов в хостах примерно равно), тем более правильно и экономично будет использование одного кластера;
  • Если в кластере есть ВМ с большой нагрузкой, за счет которой сильно увеличится резервация под слот для кластера, такую ВМ следует выносить из кластера;
  • Не стоит также забывать про параметр Failover Capacity: нам не всегда нужно создание максимально возможного числа ВМ, максимально возможное число, это максимальное количество ВМ, когда HA еще будет работать, то есть FC больше нуля. Но может понадобиться создание, например 10 ВМ, но чтобы FC был равен, скажем, 3. В этом случае придется по таблице сравнивать графу с 10 ВМ и смотреть, какое FC значение будет для общего кластера, и какое для нескольких кластеров.

Задание активистам VMware с программистским бэкграундом

Задача: Определить, как организовать кластер/кластеры таким образом, чтобы обеспечить работу наибольшего  количества виртуальных машин с Failover Capacity 1. Т.е. на какие кластеры нужно разбить и/или, как  группировать машины по кластерам. Все данные и результат должны вводиться/отображаться в браузере.

Данные на входе:
Узлы ESX

№пп Кол-во Память (Гб) Процессор (суммарно в ГГц)
1 2 шт 4 Гб 9.6 ГГц
2 6 шт 8 Гб 12 ГГц


Это реальные узлы, которые используются для построения кластера.

Данные по виртуальным машинам

№пп Процентное соотношение таких машин к общему количеству Память (Гб) Процессор (ГГц)
1 10% 2 Гб 1,5Ггц
2 35% 1 Гб 0,5Ггц
  Всего 100%  


Это гипотетическое распределение машин. Например, для провайдера услуг, можно определить их разбиение, по планам продаж (какие машины мы собираемся продавать в большем объеме, какие  - в меньшем). Для компании,  строящей собственный ЦОД, примерное распределение по тому, какие машины использовались ранее. Например, в  физической среде, с требованиями приложений, установленными на них

Результат:
Определить, как эффективно организовать HA. Сколько кластеров создать, по какому принципу распределить хосты ESX по кластерам, по какому принципу распределить виртуальные машины по узлам кластера. Еще раз, и вводные данные, и результат должен быть доступен в браузере.

Зачем стараться
Первому активисту, который решит задачу наиболее полно и правильно, по результатам внутреннего совещания мы торжественно вручим iPad2 64GB 3G.

Возможно, Вам будет также интересна следующая информация:

ha-cluster-calculation.txt · Последние изменения: 2012/07/25 14:43 — VMware vSphere and View blogger