Пришло время поговорить об арбитре и его роли в обеспечении высокой доступности . Сегодня мы расскажем как и почему гиперконвергентная архитектура позволяет предотвращать потерю данных уже в 2-узловой конфигурации. А также коснемся вопроса простоты масштабируемости: возможности плавного увеличения среды с 2 до N узлов.
Арбитр
ИТ-организации стремятся к тому, чтобы оборудование занимало, как можно меньше места. Для обеспечения высокой доступности требуется минимум два узла, но в случаях, когда два узла «не синхронизированы», такой системе нужен третий компонент, называемый арбитром или свидетелем. В случае потери прямой связи между узлами этот свидетель предотвращает состояние, когда на обоих узлах работают копии одних и тех же виртуальных машин и выполняется независимая модификация хранимых данных(split brain). Такой режим работы очень опасен, т.к. он может привести к повреждению данных и некорректной работе прикладных систем.
Что может произойти при потере связи между узлами? HPE SimpliVity записывает копию всех данных на оба узла в 2-узловом кластере, чтобы обеспечить высокую доступность системы. При отказе одного узла сохраняются вторичные копии виртуальных машин, поэтому функция VMware High Availability (HA) может восстановить их работоспособность.
Предположим, что эти узлы по какой-то причине не могут взаимодействовать друг с другом, но каждый из них продолжает выполнять операции чтения и записи, предполагая, что другой узел неисправен.
В этом сценарии есть две активные копии каждой виртуальной машины, которые работают и независимо изменяют свои данные на каждом узле. После восстановления связи между узлами появляется неопределенность. На каком из них находятся актуальные данные ВМ? Какую сторону выбрать в качестве источника восстановления? Очень маловероятно, что можно просто объединить данные, поэтому один набор данных необходимо предпочесть другому.
На схеме ниже зеленые блоки представляют данные на узле 1, а черные блоки — данные на узле 2. У этих двух наборов данных есть «общие» блоки, которые могут отличаться. Следует помнить, что они были идентичны до потери связи и начали «расходиться», поскольку использовались независимо друг от друга. Попытка простого объединения двух этих наборов данных приведет к повреждению изменившихся перекрывающихся блоков (представлены красным цветом), т. е. к потере консистентности данных.
Чтобы предотвратить такую ситуацию, в качестве свидетеля используется арбитр HPE SimpliVity. В случае проблем со связью между узлами арбитр с помощью ряда логических правил выбирает один активный узел. Он остается в режиме онлайн и перезапускает все виртуальные машины, связанные со вторым узлом, который переходит в режим офлайн для предотвращения возможности записи данных. После восстановления связи второй узел возвращается в работу, проводя синхронизацию изменений.
Хорошая новость для филиалов с ограниченным физическим пространством — для работы свидетеля на локальной площадке не нужно отдельное оборудование. Арбитр HPE SimpliVity может быть размещен на уже имеющемся сервере или ПК (в виде службы для ОС Windows) либо на другой площадке. Например, в основном ЦОДе, через который обеспечивается централизованное управление остальными площадками. Свидетель также можно разместить на других площадках. Нужно просто определить, какая архитектура лучше всего подходит для конкретного сценария использования.
Арбитр может поддерживать до 4096 виртуальных машин, распределенных среди удаленных площадок с RTT до 300 мс. В случае расширения вашей инфраструктуры сверх указанных пределов просто разверните второго, третьего, четвертого свидетеля и т. д. для поддержки нужного количества виртуальных машин на удаленных площадках.
Масштабирование стало проще
Поскольку эта серия блогов посвящена простоте HCI, основное внимание сосредоточено на небольших конфигурациях. Однако следует отметить, что в крупных конфигурациях простота не менее важна.
По мере роста рабочих нагрузок и ужесточения требований может наступить момент, когда площадки необходимо расширить за пределы двух узлов. При ограниченных локальных ИТ-ресурсах и наличии нескольких площадок, которые могут расти разными темпами, этот процесс необходимо сделать максимально простым. Из-за особенностей своей архитектуры некоторые решения HCI требуют полной перестройки при масштабировании свыше определенного количества узлов. По мере роста гиперконвергентных систем возникает желание по-другому распределять данные между узлами, а этого можно добиться, только полностью перестроив кластер.
С HPE SimpliVity дела обстоят иначе. Архитектура эффективного масштабирования специально разработана для того, чтобы начать с небольшой конфигурации (2 узла) и наращивать кластер по мере необходимости без сбоев и необходимости перестройки. Предположим, что нам требуется добавить третий узел в 2-узловой кластер. Новый узел можно добавить с помощью диспетчера развертывания HPE SimpliVity, который перед развертыванием выполняет ряд проверок. Затем на третий узел автоматически устанавливается выбранный образ ESXi, и он добавляется в кластер VMware. Это очень просто.
Также не нужно беспокоиться о балансировке виртуальных машин между узлами. Платформа виртуализации данных HPE SimpliVity автоматически отслеживает и балансирует виртуальные машины с помощью компонента, называемого Intelligent Workload Optimizer (IWO). IWO включает в себя службу балансировки ресурсов (Resource Balancer Service, RBS) и взаимодействует с планировщиком распределенных ресурсов (Distributed Resource Scheduler, DRS) VMware, обеспечивая балансировку хранилища данных и вычислительных ресурсов. RBS также работает с DRS для обеспечения локальности данных с помощью правил размещения виртуальных машин, благодаря чему виртуальные машины работают преимущественно на тех узлах, где находятся их данные. При добавлении нового узла IWO узнает о новом ресурсе и выполняет соответствующую балансировку рабочей нагрузки.
Вывод: не нужно вмешиваться! HPE SimpliVity позаботится обо всем за вас — просто, безопасно и экономически эффективно.
Гиперконвергентная инфраструктура для периферийных вычислений, часть 1. Проблемы удаленных офисов и филиалов.
Гиперконвергентная инфраструктура для периферийных вычислений, часть 2. Управление несколькими удаленными площадками.
Гиперконвергентная инфраструктура для периферийных вычислений, часть 3. Отказоустойчивость и высокая доступность.
Гиперконвергентная инфраструктура для периферийных вычислений, часть 4. Резервное копирование и аварийное восстановление.