7.2. Кластеры виртуальных машин

В этой схеме виртуальные машины сами объединяются в отказоустойчивый кластер. Преимущество такой реализации состоит в том, что она обеспечивает непрерывный доступ к службам и приложениям в гостевой системе, так как в случае сбоя виртуальной машины они смогут возобновить работу на другой машине. Поведение узлов в виртуальном кластере практически не отличается от обычного кластера.
Далее обсуждаются особенности поддержки виртуальных кластеров на платформах RHEL. В приведенных примерах гостевые системы RHEL 6 объединяют функции High Availability с дополнением Resilient Storage, предоставляющим инструменты для повышения отказоустойчивости подсистемы хранения данных (GFS2, clvmd, cmirror).
  • На платформах RHEL 5.3+ Xen можно построить виртуальные кластеры с операционными системами RHEL 5.3+.
    • Изоляция неисправных узлов в таком кластере осуществляется при помощи fence_xvm или fence_scsi.
    • Для нормальной работы fence_xvm необходимо, чтобы кластер физических серверов поддерживал fence_xvmd, а узлы виртуального кластера использовали агент изоляции fence_xvm.
    • Общее хранилище может быть построено на блочных устройствах iSCSI или Xen.
  • Платформы RHEL 5.5+ KVM не поддерживают виртуальные кластеры.
  • Платформы RHEL 6.1+ KVM поддерживают виртуальные кластеры с операционными системами RHEL 6.1+ и RHEL 5.6+.
    • В состав кластера могут входить и физические, и виртуальные узлы.
    • В кластерах RHEL 5.6+ изоляция неисправных узлов осуществляется с помощью fence_xvm или fence_scsi.
    • В кластерах RHEL 6.1+ изоляция узлов осуществляется с помощью fence_xvm (из пакета fence-virt) или fence_scsi.
    • Если для изоляции узлов используется агент fence_virt или fence_xvm, то на серверах RHEL 6.1+ KVM должен работать fence_virtd.
    • fence_virtd может работать в трех режимах:
      • В автономном режиме связи гостевых систем с сервером жестко определены, поэтому живая миграция невозможна.
      • Отслеживание живой миграции средствами Openais Checkpoint. Для этого необходимо, чтобы физические узлы были объединены в кластер.
      • Отслеживание живой миграции средствами QMF (Qpid Management Framework) из пакета libvirt-qpid. Это не требует наличия кластера физических узлов.
    • Общее хранилище кластера может быть построено на блочных устройствах iSCSI или KVM.
  • На платформах RHEV-M (Red Hat Enterprise Virtualization Management) 2.2+ и 3.0 могут создаваться кластеры виртуальных машин RHEL 5.6+ и RHEL 6.1+.
    • Все гостевые операционные системы в кластере должны быть одного типа: RHEL 5.6+ или RHEL 6.1+.
    • В состав кластера могут входить и физические, и виртуальные узлы.
    • За изоляцию узлов на платформе RHEV-M 2.2+ отвечает агент fence_scsi, на RHEV-M 3.0 — fence_scsi и fence_rhevm.
      • Для нормальной работы fence_scsi необходимо, чтобы серверы iSCSI поддерживали алгоритмы постоянного резервирования SCSI-3. Эту информацию следует заранее уточнить у производителя. Так, сервер iSCSI, входящий в стандартную поставку Red Hat Enterprise Linux, не поддерживает постоянное резервирование SCSI-3 и, как следствие, не сможет использовать fence_scsi.
  • VMware vSphere 4.1, VMware vCenter 4.1, VMware ESX и ESXi 4.1 поддерживают виртуальные кластеры с гостевыми операционными системами RHEL 5.7+ и RHEL 6.2+. VMware vSphere 5.0, vCenter 5.0, ESX и ESXi 5.0 тоже можно использовать, но исходная версия VMware vSphere 5.0 включает неполную схему WDSL, поэтому fence_vmware_soap не будет работать в исходной реализации. О том, как снять это ограничение, можно узнать из базы знаний Red Hat: https://access.redhat.com/knowledge/.
    • Все гостевые операционные системы в кластере должны быть одного типа: RHEL 5.7+ или RHEL 6.1+.
    • В состав кластера могут входить и физические, и виртуальные узлы.
    • Для нормальной работы fence_vmware_soap потребуется загрузить пакет с дополнительными Pearl API с сайта VMware и установить его в гостевых системах RHEL.
    • В противном случае можно настроить изоляцию fence_scsi.
    • Общее хранилище может быть построено на RAW-дисках VMware и блочных устройствах iSCSI.
    • В виртуальных кластерах на базе VMware ESX изоляция узлов должна осуществляться средствами fence_vmware_so_ap или fence_scsi.
  • Виртуальные кластеры Hyper-V не поддерживаются.

7.2.1. Fence_scsi и общее хранилище iSCSI

  • Во всех перечисленных выше схемах на базе исходных решений хранения данных можно создать общее хранилище iSCSI и настроить агент изоляции fence_scsi.
  • fence_scsi изолирует вышедшие из строя узлы, отключая их доступ к хранилищу путем удаления их ключей регистрации с дисков. Для этого цели iSCSI должны поддерживать постоянное резервирование iSCSI-3 и команду "PREEMPT AND ABORT". Эту информацию следует заранее уточнить у производителя.
  • Программное обеспечение сервера iSCSI в стандартной сборке RHEL не поддерживает постоянное резервирование SCSI-3 и не сможет использовать fence_scsi. Возможно, вы решите остановиться на других методах изоляции — fence__vmware или fence_rhevm.
  • Если на всех узлах виртуального кластера настроен fence_scsi, то объединять физические серверы (RHEL 5 Xen/KVM и RHEL 6 KVM) в кластер не обязательно.
  • Совместное использование общего хранилища iSCSI с подключенными напрямую устройствами не допускается.