VSA - виртуальное общее хранилище - vSphere Storage Appliance - часть 1 (построение)

Смотреть видео

Для просмотра этого содержимого требуется Adobe Flash Plugin.

Вторая часть>>

Введение

В этой статье мы расскажем Вам про актуальное на сегодня решение от VMware – vSphere Storage Appliance или VSA. Storage Appliance позволяет объединить внутренние диски серверов в некоторое подобие программного рейд и построить с помощью полученного общего хранилища отказоустойчивый кластер на двух или трех физических серверах. 

Основная идея использования VSA заключается в том, что при использовании, к примеру, 3-х серверов для виртуализации Вы можете обойтись без покупки системы хранения данных. Сам же VSA не требует покупки отдельных лицензий VMware и входит в редакцию vSphere Essentials Plus. Напомним, что редакция vSphere Essentials Plus – самая низкая редакция, поддерживающая технологии vMotion (живая миграция виртуальных машин) и High Availability (автоматический перезапуск виртуальных машин при выходе из строя одного или нескольких физических серверов). 

В нашем случае мы будем называть датастором хранилище, которое будет предназначаться для хранения виртуальных машин и будет видно со стороны ESXi. В случае трех хостов таких хранилищ будет всегда три. На картинке это и есть VSADs-0, 1 и 2. vSphere Storage Appliance Datastore.
Раздел 1, или как тут написано volume 1, то место где будут храниться данные датастора 0.На каждом из этих серверов будет создан раздел (ровно половина пространства), на котором будут храниться данные датасторов. На вторую половину пространства  будут добавлены реплики других разделов. Если, например, откажет volume 1, то датастор 0 – будет брать данные со второго раздела второго сервера.
В этой презентации мы поговорим о том, как устроен кластер VSA, дадим немного теории. В следующих презентациях мы покажем, как будет вести себя кластер VSA (а главное, приложения, которые запущены на кластере при выходе из строя серверов, коммутаторов сети, сетевых интерфейсов и т.д.).

Какие элементы


VSA включает в себя три основных компонента:

  • vSphere Storage Appliance – виртуальный модуль, который автоматически разворачивается с помощью VSA Manager. Этот модуль является виртуальной машиной, он нужен для того, чтобы на основе выделенных ему разделов сервера поднять датасторы в виде NAS хранилищ. Таких ВМ будет подниматься 2 или три в зависимости от количества хостов в кластере.
  • VSA Manager – плагин, который устанавливается на сервере vCenter. С помощью него и происходит разворачивание кластера и управление им;
  • VSA Cluster Service – сервис, который устанавливается либо на ВМ с vCenter Server, либо на отдельной машине под управлением Windows или Linux. Данный сервис нужен лишь для кластера с двумя гипервизорами. Он необходим, если один из серверов падает, в этом случае он имитирует сервер ESXi. Это не даст никаких лишних датасторов, но поможет сохранить кластер VSA в целостности; по сути, это своеобразный маяк для хоста, который не отвалился от общей сети, он нужен, чтобы хост понимал, что он не изолирован, иначе, если сеть пропадет между двумя хостами, а кластер сервиса не будет, оба хоста будут думать, что они изолированы и снимут свои блокировки с виртуальных машин.

Как инфраструктура должна выглядеть

Теперь немного про подключения сетевых компонентов. Выглядеть оно должно следующим образом (это показано для кластера с тремя гипервизорами):

\\В этом случае используется 3 сервера ESXi, на каждом из которых по 4 физических сетевых адаптера, и они соединены двумя физическими коммутаторами для обеспечения отказоустойчивости.

Кластер VMware VSA использует два типа сетевого трафика: называет он их условно Front-End Traffic и Back-End Traffic.

Front-End Traffic включает в себя трафик между всеми хостами и датасторами. Если Front-end сеть перестает функционировать, все ВМ на этом хосте перестанут работать и HA поднимет все ВМ на втором сервере с репликой. Данные виртуальной машины, записывающиеся на диски хостов, проходят как раз по сети front-end.

Back-End Traffic включает в себя репликацию данных между датастором на одном хосте и его репликой на другом. Если Back-end сеть перестает функционировать, синхронизация дисков на разных хостах нарушается, и в дальнейшем при отказе хоста мы потеряем данные, начиная с момента падения Back-end сети.

Здесь показана сетевая архитектура одного из хостов:

\\Для распределения Front-End и Back-End сетей, необходимо разнести их трафики по разным виртуальным свичам одного хоста, чтобы эти трафики не ходили по одним и тем же сетевым интерфейсам. На картинке разнесены два интерфейса vmnic0 и vmnic1, которые в свою очередь присоединяются к физическому dual-port адаптеру. Минимум на каждом сервере должно быть 4 сетевых интерфейса. Для устранения единой точки отказа необходимо создать резервный сетевой канал. Для этого добавлен еще один двухпортовый сетевой адаптер, к которому идут vmnic2 и vmnic3. В этом случае при падении физических коммутаторов, либо при падении сетевых адаптеров ничего страшного не произойдет.

Как выглядит наша инфраструктура и ее ограничения

В нашей инфраструктуре мы используем два хоста в кластере, в каждом из этих хостов находится по два сетевых адаптера. В этом случае для сохранения резервного сетевого канала мы настроили и back-end и front-end на одном виртуальном коммутаторе. В production сетях это делать ЗАПРЕЩЕНО, поскольку решение не будет поддерживаться, но для нашей лабораторной это вполне подойдет.

Демонстрация нашей инфраструктуры

Теперь о том, как выглядит плагин VSA Manager. Он доступен по вкладке VSA и содержит 3 закладки: взгляд со стороны Датасторов, со стороны модулей VSA и общая карта кластера VSA.

В закладке DataStores мы видим оба наших датастора, созданные с помощью VSA, это VSA DataStore 1 и 2. Тут доступен их статус, свободное и общее место на дисках, а также написано, на каком модуле в данный момент этот датастор является активным. Например, в нашем случае сейчас VSA Datastore 1 является активным на модуле VSA-0.

В закладке Appliance мы видим подробную информацию о модулях VSA. Именно в этом окне лучше всего всегда смотреть информацию о кластере VSA. Тут написаны статусы модулей, к какому хосту относится каждый из модулей, какой из датасторов в данный момент является на модуле активным, а какой – репликой. Например, модуль VSA-1 находится на 7 хосте, на нем нулевой датастор является активным, а первый – репликой.

И последняя закладка – это карта кластера. Тут мы видим, что каждый из датасторов показан аж три раза, на самом деле крайний датастор – это логическое представление со стороны vSphere, а физическими дисками являются два других. Представим ситуацию, когда связь между хостами пропадает, вот что в этом случае происходит. Все зависит от того, какой из хостов остался в сети и видит Cluster Services. Например, если 7 хост остался в сети, то его оба датастора станут активными, а у 8 – репликами и 8 погасит все свои ВМ, снимет блокировки и будет ждать, когда связь восстановится. После того, как сеть появится, 8 сервер синхронизируется с обоими активными датасторами 7 сервера и далее сделает у себя один из датасторов активным, и уже 7 хост будет синхронизировать свою реплику с 8 сервером. Вот почему нельзя, чтобы в инфраструктуре с двумя хостами отсутствовал кластер сервис. В этом случае при разрыве сети оба хоста будут думать, что они изолированы, а это значит, что они откажутся от своих ВМ, погасят их и сделают все свои диски репликами. Ни к чему хорошему это не приведет.

vsphere-storage-appliance-5-1-part1.txt · Последние изменения: 2013/05/22 09:52 — VMware vSphere and View blogger