Вопрос или проблема
Привет, у меня следующая конфигурация для использования vSphere с HA:
Моя проблема заключается в поиске разумного решения для HA для сервера базы данных. Требования к IOP для сервера базы данных очень высоки, поэтому файлы базы данных распределены между тремя локальными массивами SSD в RAID 10. Сетевое хранилище составляет 10 Гбит/с, и хотя оно не соответствует требованиям производительности в долгосрочной перспективе, я хотел бы иметь возможность автоматического переключения на общее хранилище в случае сбоя хоста.
У кого-нибудь есть предложения, как я могу это реализовать? Возможно, выбрать последнее резервное изображение на общем хранилище?
Спасибо
*на vmware essentials plus.
vSphere Storage Appliance может “делить” локальное хранилище между разными хостами vmware, но, кажется, оно не включено в essentials plus. Существует vSphere Replication, что является vmware-устройством, которое может реплицировать виртуальную машину базы данных и ее локальное хранилище на локальное хранилище другого хоста. Оно также включено в essentials plus. Однако это не будет автоматизировано как vSphere HA (по крайней мере, я так не думаю), и вы не получите лучший RPO, чем 15 минут. Если это приемлемо, это, вероятно, лучший выбор.
Лучшим решением было бы пересмотреть требования по вводу-выводу базы данных и рассмотреть возможность использования SAN, который может поддерживать ее и остальную часть потребностей вашего кластера. Большинство производителей SAN предлагают SSD-опции. Или, если это не возможно, издержки переноса базы данных на выделенное оборудование и использование предложений HA приложения (Oracle RAC/dataguard, mysql master-master и т.д.) для удовлетворения ваших нужд.
У StarWind есть родная реализация Hyper-V. Они продают это с 2011 года. VMware имеет то же самое, называемое vSAN, которое в настоящее время находится в стадии бета-тестирования. Таким образом, StarWind предвидел будущее задолго до того, как вся ИТ-индустрия пошла в правильном направлении 🙂 Главный момент здесь – запуск внутри ГИПЕРВИЗОРА, а не внутри гостевой виртуальной машины.
Вы можете реализовать пакет синхронной или асинхронной репликации данных, такой как SIOS SteelEye. Это программное обеспечение для управления кластерами, которое позволит вам иметь одно или несколько зеркал одного и того же сервера, управление отказом в обслуживании, IP-адресами и, конечно же, данными.
Но на самом деле вы избегаете одной из лучших функций VMware: высокой доступности. Можно ли улучшить возможности вашего NAS? Возможно, вы можете использовать кэширование на уровне хоста для ESXi.
Пожалуйста, изложите требования IOPS вашего сервера базы данных.
.
Ответ или решение
Обеспечение высокой доступности (HA) для виртуальных машин (VM) на локальном хранилище представляет собой сложную, но решаемую задачу. В описанной вами архитектуре действует ряд ограничений, связанных с высокими требованиями к IOPS для вашего сервер баз данных (БД), который использует локальные массивы SSD RAID 10. Давайте подробнее рассмотрим проблему и возможные решения.
Теория (Theory)
Основная идея в любой системе высокой доступности состоит в том, чтобы минимизировать время простоя сервисов и данных, обеспечивая их доступность в случае возникновения сбоев оборудования, сети или программного обеспечения. В контексте виртуальных сред на базе VMware, это обычно достигается с помощью таких технологий, как vSphere High Availability (HA), Fault Tolerance (FT), репликация и распределенные системы хранения данных (например, vSAN).
Проблемы в текущей среде:
-
Локальное хранилище: Использование локального хранения ограничивает возможности передачи данных между хостами в случае сбоя. Как следствие, невозможно просто перенести VM на другой хост без предоставления доступа к тем же данным.
-
Высокие IOPS: БД, требующая высоких IOPS, ускоряет локальные SSD RAID 10, что делает медицинским, но затрудняет использование сетевых или общих хранилищ для такого уровня нагрузки.
Возможные решения для обеспечения HA:
- vSphere Replication: Позволяет реплицировать виртуальные машины и их локальные данные на другой хост. Это может предоставить возможность автоматического перехода, хотя и с RPO (Recovery Point Objective) около 15 минут.
- vSAN или другой программно-определяемый сетевой массив: Хотя и недоступен в комплекте Essentials Plus, подобные решения дают возможность разделять локальное хранилище между ESXi хостами.
- Третьесторонние решения, такие как SIOS SteelEye или StarWind: Эти решения могут работать на уровне гипервизора и обеспечивают кластерное управление, включая репликацию данных.
Пример (Example)
Рассмотрим пример интеграции vSphere Replication. Вы можете настроить репликацию критических виртуальных машин на вторичный хост ESXi. Это решение простое в реализации и демонстрирует себя достаточно надежно в случаях планового обслуживания или незначительных сбоев. Однако стоит помнить про ограничения, касающиеся автоматизации процесса переключения на резервный вариант.
Другое решение может быть реализовано с помощью SIOS SteelEye. Этот инструмент позволит вам создать зеркальные копии серверов и управлять фейловером сервисов и IP-адресов. И хотя это комплексное решение, оно предоставляет значительные возможности для повышения доступности сервера БД.
Применение (Application)
Рекомендуется сначала провести анализ и реорганизацию требований к IOPS и рассмотреть интеграцию более стабильной системы хранения, например, SAN с возможностью использования SSD. Это автоматизирует управление и упрощает развертывание решений для HA.
Если интеграция SAN невозможна, рекомендуется использовать репликацию на уровне vSphere Replication, что позволит хотя бы частично компенсировать недостатки текущей инфраструктуры.
Также не стоит пренебрегать и оценкой возможностей использования аппаратных средств на уровне приложений: такие технологии, как Oracle RAC или MySQL Master-Master, предоставляют встроенные возможности масштабирования и высокой доступности. Эти подходы позволят вам более эффективно управлять высокими нагрузками и обеспечат надежность и производительность вашей системы.
Таким образом, актуализация инфраструктуры решения с учетом предложенных способов позволит минимизировать риски потери доступа к данным БД в случае сбоев, обеспечивая при этом нужный уровень производительности.