Главная » Хабрахабр » vSAN в облаке на базе VMware

vSAN в облаке на базе VMware

Даже у хорошо спроектированной системы хранения данных (далее СХД) в процессе эксплуатации выявляются проблемы, связанные со снижением производительности. Задачи хранения и доступа к данным являются болевой точкой для любой информационной системы. Отдельного внимания заслуживает комплекс проблем масштабирования, когда количество задействованных ресурсов приближается к установленным лимитам, заложенным разработчиками СХД.

Большинство клиентов до сих пор выбирают способ хранения и доступа к данным с учетом характеристик физических интерфейсов (SAS / SATA / SCSI), а не реальных потребностей используемых приложений.
Еще десяток лет назад это было логичным решением. Фундаментальной причиной возникновения этих проблем является традиционная архитектура, основанная на жесткой привязке к аппаратным характеристикам используемых устройств хранения данных. Борьба шла и за объемы кэшей RAID-контроллеров и за опции, предотвращающие потерю данных. Системные администраторы тщательно выбирали накопители информации с требуемой спецификацией, например SATA/SAS, и рассчитывали на получение уровня производительности, исходя из аппаратных возможностей дисковых контроллеров. Сейчас такой подход к решению проблемы не является оптимальным.

Использование виртуализации позволяет гибко использовать существующие аппаратные ресурсы и гарантировать требуемый уровень производительности. В текущих условиях при выборе СХД имеет смысл отталкиваться не от физических интерфейсов, а от производительности, выраженной в IOPS (количество операций ввода-вывода в секунду). Мы со своей стороны готовы предоставить ресурсы с теми характеристиками, которые реально необходимы приложению.

Виртуализация СХД

С развитием систем виртуализации требовалось найти инновационное решение для хранения и доступа к данным, одновременно обеспечивая отказоустойчивость. Это стало отправной точкой для создания SDS (Software-Defined Storage). Чтобы удовлетворять бизнес-потребностям, такие хранилища проектировались с разделением программного и аппаратного обеспечения.

Логика хранения стала абстрагироваться на программном уровне. Архитектура SDS в корне отличается от традиционной. Организация хранения стала проще за счет унификации и виртуализации каждого из компонентов такой системы.

Этим фактором чаще всего оказывается некорректная оценка потребностей используемых приложений и неверная оценка рисков. Что же является основным фактором, препятствующим внедрению SDS повсеместно? Мало кто думает — что будет, когда объем информации и требуемая производительность превысит возможности выбранной архитектуры. Для бизнеса выбор решения зависит от затрат на внедрение, исходя из текущих потребляемых ресурсов. Мышление на базе методологического принципа «не следует множить сущее без необходимости», более известного как «лезвие Оккама», обуславливает выбор в пользу традиционных решений.

Информация это ресурс, а следовательно, риск ее потери необходимо страховать. Лишь немногие понимают, что необходимость в масштабировании и надежности хранения данных важнее, чем кажется на первый взгляд. Потребуется воспользоваться гарантией либо купить новое оборудование. Что будет, когда традиционная СХД выйдет из строя? Это может стать «черным днем» для любой организации, которая не сможет продолжать использовать привычные собственные сервисы. А если СХД снята с производства или у нее закончился «срок жизни» (так называемый EOL — End-of-Life)?

Зато есть системы, которые способны без проблем пережить отказ одного или нескольких компонентов. Не существует систем, которые бы не имели ни одной точки отказа. Вот только «лимит прочности» традиционных СХД заложен аппаратно, а вот в виртуальных СХД он определяется в программном слое. И виртуальные, и традиционные СХД создавались с учетом того, что рано или поздно произойдет сбой.

Интеграция

Кардинальные перемены в IT-инфраструктуре всегда нежелательное явление, чреватое простоями и потерей средств. Только плавное внедрение новых решений дает возможность избежать негативных последствий и улучшить работу сервисов. Именно поэтому Selectel разработал и запустил облако на базе VMware, признанного лидера на рынке систем виртуализации. Созданная нами услуга позволит каждой компании решить весь комплекс инфраструктурных задач, в том числе и по хранению данных.

Разумеется, что рассматривались как традиционные системы хранения данных, так и SDS. Расскажем о том, как именно мы решили вопрос с выбором системы хранения данных, а также какие преимущества дал нам этот выбор. Чтобы четко понимать все аспекты эксплуатации и риски, предлагаем детально углубиться в тему.

Еще на этапе проектирования к СХД предъявлялись следующие требования:

  • отказоустойчивость;
  • производительность;
  • масштабирование;
  • возможность гарантировать скорость работы;
  • корректная работа в экосистеме VMware.

Использование традиционных аппаратных решений не могло обеспечить требуемый уровень масштабирования, поскольку невозможно постоянно наращивать объем хранилища из-за ограничений архитектуры. Также большую сложность представляло резервирование на уровне целого дата-центра. Именно поэтому мы обратили внимание на SDS.

Среди этих решений можно отметить: На рынке SDS присутствует несколько программных решений, которые бы подошли нам для построения облака на базе VMware vSphere.

  • Dell EMC ScaleIO;
  • Datacore Hyper-converged Virtual SAN;
  • HPE StoreVirtual.

Указанные решения пригодны для использования c VMware vSphere, однако не встраиваются в гипервизор и запускаются отдельно. Поэтому выбор был сделан в пользу VMware vSAN. Рассмотрим детально, как выглядит виртуальная архитектура такого решения.

Архитектура

Изображение взято из официальной документации

Данные виртуальных машин равномерно «размазаны» между всеми хостами, а масштабирование осуществляется добавлением хостов или установкой на них дополнительных дисковых накопителей. В отличие от традиционных СХД вся информация не хранится в какой-то одной точке. Поддерживается два варианта конфигурации:

  • AllFlash-конфигурация (только твердотельные накопители, как для хранения данных, так и для кэша);
  • Hybrid-конфигурация (магнитные накопители для хранения данных и твердотельные для кэша).

Процедура добавления дискового пространства не требует дополнительных настроек, например, создания LUN (Logical Unit Number, логических номеров дисков) и настройки доступа к ним. Как только хост добавлен в кластер, его дисковое пространство становится доступным для всех виртуальных машин. Такой подход имеет ряд существенных преимуществ:

  • отсутствие привязки к производителю оборудования;
  • повышенная отказоустойчивость;
  • обеспечение целостности данных в случае сбоя;
  • единый центр управления из консоли vSphere;
  • удобное горизонтальное и вертикальное масштабирование.

Однако эта архитектура предъявляет повышенные требования к сетевой инфраструктуре. Для обеспечения максимальной пропускной способности, в нашем облаке сеть построена по модели Spine-Leaf.

Сеть

Традиционная трехуровневая сетевая модель (ядро / агрегация / доступ) имеет ряд существенных недостатков. Ярким примером являются ограничения Spanning-Tree протоколов.

В модели Spine-Leaf используется только два уровня, что дает следующие преимущества:

  • предсказуемое расстояние между устройствами;
  • трафик идет по наилучшему маршруту;
  • легкость масштабирования;
  • исключение ограничений протоколов уровня L2.

Ключевой особенностью такой архитектуры является то, что она максимально оптимизирована для прохождения «горизонтального» трафика. Пакеты данных проходят только через один хоп, что позволяет четко оценивать задержки.

Таким образом, каждый физический хост получает высокую скорость доступа ко всем объектам хранилища. Физическое соединение обеспечивается с помощью нескольких 10GbE-линков на каждый сервер, пропускная способность которых объединяется с помощью протокола агрегации.

Обмен данными реализуется с помощью проприетарного протокола, созданного VMware, позволяющего обеспечить быструю и надежную работу сети хранения на Ethernet-транспорте (от 10GbE и выше).

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

Отказоустойчивость

  1. FTT (Failures To Tolerate). Обозначает количество отказов хостов, которые кластер способен обработать, не прерывая штатной работы.
  2. FTM (Failure Tolerance Method ). Метод обеспечения отказоустойчивости на уровне дисков.

    Mirroring (зеркалирование).
    a.

    Изображение взято из блога VMware

    Ближайшим аналогом такого метода является RAID-1. Представляет собой полное дублирование объекта, причем реплики всегда находятся на разных физических хостах. Этот параметр настраивается посредством задания опции FTT. Его использование позволяет кластеру штатно обработать до трех отказов любых компонентов (диски, хосты, потеря сети и прочее).

    При увеличении значения, количество экземпляров будет составлять N+1. По-умолчанию эта опция имеет значение 1, при этом для объекта создается 1 реплика (всего 2 экземпляра на разных хостах). Таким образом, при максимальном значении FTT=3 на разных хостах будут находиться 4 экземпляра объекта.

    Допускается использование как в гибридной, так и в AllFlash-конфигурации. Такой метод позволяет достичь максимальной производительности в ущерб эффективности использования дискового пространства.

    Erasure Coding (аналог RAID 5/6).
    b.

    Изображение взято из блога cormachogan.com

    В процессе записи каждого объекта вычисляются соответствующие блоки четности, позволяющие однозначно восстановить данные при возникновении сбоя. Работа данного метода поддерживается исключительно на AllFlash-конфигурациях. Такой подход существенно экономит дисковое пространство по сравнению с Mirroring.

    Тем не менее, с учетом производительности AllFlash-конфигурации, этот недостаток нивелируется, делая использование Erasure Coding приемлемым вариантом для большинства задач. Разумеется, работа подобного метода повышает накладные расходы, которые выражаются в снижении производительности.

    Как только необходимые элементы сгруппированы, это приводит к распределению данных по разным узлам с учетом доменов отказа. Кроме того, VMware vSAN вводит понятие «доменов отказа», представляющих собой логическое группирование серверных стоек или дисковых корзин. Это позволяет кластеру пережить потерю целого домена, поскольку все соответствующие реплики объектов будут располагаться на других хостах в другом домене отказа.

    Каждая дисковая группа содержит в себе носители двух типов — cache и capacity. Минимальным доменом отказа является дисковая группа, представляющая собой логически связанные дисковые накопители. Кэширующие носители помогают ускорить работу магнитных дисков и уменьшить задержку при доступе к данным. В качестве cache-носителей система позволяет использовать только твердотельные диски, а в качестве capacity-носителей могут выступать как магнитные, так и твердотельные диски.

Реализация

Поговорим о том, какие ограничения существуют в архитектуре VMware vSAN и зачем они нужны. Вне зависимости от используемых аппаратных платформ, архитектура предусматривает следующие ограничения:

  • не более 5 дисковых групп на хост;
  • не более 7 capacity-носителей в дисковой группе;
  • не более 1 cache-носителя в дисковой группе;
  • не более 35 capacity-носителей на хост;
  • не более 9000 компонентов на хост (включая witness-компоненты);
  • не более 64 хостов в кластере;
  • не более 1 vSAN-datastore на кластер.

Зачем это нужно? Пока указанные лимиты не превышены, система будет функционировать с заявленной производительностью, поддерживая баланс между производительностью и объемом хранения. Это позволяет гарантировать корректную работу всей виртуальной СХД в целом.

Не рекомендуется заполнять более 70% общего объема хранилища. Помимо указанных ограничений следует помнить одну важную особенность. Процедура достаточно ресурсоемкая и может серьезно сказаться на производительности дисковой подсистемы. Дело в том, что при достижении 80% автоматически запускается механизм ребалансировки, и система хранения начинает перераспределять данные по всем хостам кластера.

Давайте рассмотрим каждый из них по порядку. Чтобы удовлетворить потребности самых разных клиентов, нами было реализовано три пула хранения данных для удобства использования в различных сценариях.

Пул с быстрыми дисками

Приоритетом для создания этого пула было получить хранилище, которое обеспечит максимальную производительность для размещения высоконагруженных систем. Серверы из этого пула используют пару Intel P4600 в качестве кэша и 10 Intel P3520 для хранения данных. Кэш в этом пуле используется таким образом, чтобы чтение данных происходило напрямую с носителей, а операции записи происходили через кэш.

Такая модель схожа с обычным массивом RAID 5/6, но на уровне объектного хранилища. Для увеличения полезной емкости и обеспечения отказоустойчивости используется модель хранения данных под названием Erasure Coding. Чтобы исключить вероятность повреждения данных, vSAN использует механизм вычисления контрольных сумм для каждого блока данных, размером 4К.

При выявлении несовпадения контрольных сумм, а следовательно, повреждения данных, vSAN автоматически восстановит файлы путем перезаписи. Проверка осуществляется в фоновом режиме во время операций чтения/записи, а также для «холодных» данных, доступ к которым не запрашивался в течение года.

Пул с гибридными дисками

В случае с этим пулом, его основной задачей является предоставление большого объема данных, обеспечивая при этом хороший уровень отказоустойчивости. Для многих задач скорость доступа к данным не является приоритетной, гораздо более важен объем, а еще стоимость хранения. Использование твердотельных накопителей в качестве такого хранилища будет иметь необоснованно высокую стоимость.

Гибридная схема работы ускоряет доступ к часто запрашиваемым данным, за счет кэширования операций чтения и записи. Этот фактор и послужил причиной создания пула, который представляет собой гибрид из кэширующих твердотельных накопителей (как и в других пулах это Intel P4600) и жестких дисков корпоративного уровня, разработанных компанией HGST.

Каждый объект разбивается на идентичные компоненты и система распределяет их по разным хостам. На логическом уровне данные зеркалируются для исключения потери в случае сбоя оборудования.

Пул с Disaster Recovery

Задействование технологии Stretched vSAN позволило нам разнести хранилище между дата-центрами Цветочная-2 в Санкт-Петербурге и Дубровка-3 в Ленинградской области. Основной задачей пула является достижение максимального уровня отказоустойчивости и производительности. На логическом уровне это 2 дисковые группы на хост. Каждый сервер из данного пула оснащен парой емких и высокоскоростных накопителей Intel P4600 для работы кэша и по 6 штук Intel P3520 для хранения данных.

Так же, как и в пуле с быстрыми дисками операции записи проходят через кэш, а чтение осуществляется напрямую. AllFlash-конфигурация лишена серьезного недостатка — резкого падения IOPS и увеличения очереди дисковых запросов при увеличенном объеме операций произвольного доступа к данным.

Данные каждой виртуальной машины зеркалируются внутри одного дата-центра и при этом синхронно реплицируются в другой, принадлежащий нам, дата-центр. Теперь о главном отличии от остальных пулов. Даже полная потеря дата-центра не затронет данные. Таким образом, даже серьезная авария, такая как полное нарушение связности между дата-центрами не станет проблемой.

Гости проводимого нами мероприятия SelectelTechDay 2018 смогли собственными глазами увидеть, как кластер Stretched vSAN пережил полный отказ площадки. Авария с полным отказом площадки — ситуация достаточно редкая, однако vSAN с честью может ее пережить, не потеряв данные. Все механизмы сработали именно так, как было запланировано, а данные остались нетронутыми. Виртуальные машины стали доступны уже через одну минуту после того, как все серверы на одной из площадок были выключены по питанию.

Одним из таких изменений стало появление новых виртуальных «сущностей», к которым относятся и witness appliance. Отказ от привычной архитектуры хранения данных влечет за собой массу изменений. При этом самих данных на witness-компонентах не хранится, только метаданные о процессе записи. Смысл этого решения в том, чтобы отслеживать процесс записи реплик данных и определять, какая из них является актуальной.

Этот механизм вступает в действие в случае аварии, когда в процессе репликации происходит сбой, результатом которого является рассинхронизация реплик.

Каждый компонент обладает «правом голоса», и ему присваивается некоторое количество голосов (1 и более). Чтобы определить, какая из них содержит актуальную информацию, используется механизм определения кворума. Такое же «право голоса» имеют и witness-компоненты, играющие роль арбитров, при возникновении спорной ситуации.

Кворум достигается только в том случае, когда для объекта доступна полная реплика и количество текущих «голосов» составляет более 50%.

Заключение

Выбор VMware vSAN, как системы хранения данных, стал для нас достаточно важным решением. Этот вариант прошел нагрузочное тестирование и проверку отказоустойчивости, прежде чем был включен в проект нашего облака на базе VMware.

По результатам тестов стало ясно, что заявленный функционал работает как положено и удовлетворяет всем требованиям нашей облачной инфраструктуры.

Добро пожаловать в комментарии. Есть о чем рассказать на основе собственного опыта работы с vSAN?


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Из песочницы] От var b до собеседования

Вы почти закончили универ или колледж? Вас пригласили на собеседования, но вы идете туда без подготовки? У вас нет образования (высшего), но хотите работать программистом или в сфере IT? Речь пойдёт по большей степени о поиске работы, я буду говорить ...

OpenSceneGraph: Основы работы с геометрией сцены

OpenGL, являющийся бэкэндом для OpenSceneGraph, использует геометрические примитивы (такие как точки, линии, треугольники и полигональные грани) для построения всех объектов трехмерного мира. Эти данные хранятся в специальных массивах. Эти примитивы задаются данными об их вершинах, в которые входят координаты вершин, ...