Введение

Статья описывает возможности и архитектурные особенности облачной платформы Citrix Cloud и набора сервисов Citrix Workspace. Данные решения являются центральным элементом и основой для реализации концепции цифровых рабочих мест (digital workspaсe) от компании Citrix.

В настоящей статье я попытался разобраться и сформулировать причинно-следственные связи между облачными платформами, сервисами и подписками Citrix, описание которых в открытых источниках компании (citrix.com и docs.citrix.com) выглядит местами очень туманно. Облачные технологии – по-другому видимо никак! Стоит отметить, что архитектура и технологии раскрыты в целом вменяемо. Сложности возникают в понимании иерархической взаимосвязи между сервисами и платформами:

• какая платформа первична — Citrix Cloud или Citrix Workspace Platform?
• в какую из платформ, указанных выше, входят многочисленные сервисы Citrix, необходимые для построения инфраструктуры цифровых рабочих мест?
• сколько стоит это удовольствие и в каких вариантах его можно получить?
• возможно ли реализовать все фичи digital workspaсe Citrix без использования Citrix Cloud?

Ответы на эти вопросы и знакомство с решениями Citrix для цифровых рабочих мест под катом.

Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR
• Тестирование решения, определение оптимальных настроек и режимов работы
• Запуск решения в промышленную (коммерческую) эксплуатацию

Как оказалось – не зря. Услуга стабильно функционирует, клиенты могут бэкапить свои виртуалки, а у нас появилась определенная экспертиза, которой мы хотим поделиться.

В этой статье мы хотим рассказать о результатах нагрузочного тестирования VBR для двух наиболее популярных режимов работы бэкап-прокси с учетом вариации количества параллельных задач.

Введение

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

Для оценки производительности хранилища, дабы понимать его возможности для выполнения реальных задач, необходимо проведение нагрузочного тестирования. Самыми простыми в реализации являются синтетические тесты, выполняемые, например, с помощью таких популярных утилит как Iometer и Fio. Классическое применение: тестирование локального хранилища узла либо внешней СХД с одного или нескольких узлов.

С виртуальной инфраструктурой дела обстоят несколько сложнее, она состоит из множества хостов, на которых крутятся десятки ВМ. Даже небольшая инсталляция из двух-четырех хостов может легко держать около 100 ВМ, не говоря о средних и больших инфраструктурах из десятков и сотен хостов.

Тестировать общее хранилище для такой инфраструктуры путем запуска Iometer/Fio на одной или нескольких ВМ либо с выделенного узла на голом железе будет некорректным. Такое тестирование должно быть распределенным и обеспечивать параллельную генерацию ввода/вывода и централизованный учет результатов с множества ВМ со всех хостов кластера vSphere. Только такой подход позволит сэмулировать нагрузку реального высоконагруженного виртуального кластера.

Лично я пробовал на своем тестовом кластере vSphere vSAN 6 update 3 из 4х хостов ручками развернуть 4 ВМ на Винде с Iometer, через командную строку подключить Dynamo на 3х ВМ к консоли Iometer на четвертой ВМ, с которой и проводил распределенное тестирование. Даже для 4х ВМ дело это скучное и неблагодарное, разворачивать по несколько ВМ на хост вручную вообще не вариант.

Конечно можно воспользоваться скриптами, средствами автоматизации и сделать всё красиво, но я не умею. Поэтому для таких как я небольшая группа разработчиков VMware выпустила и развивает бесплатную утилиту HCIBench, о ней мы и будем говорить в данной статье.

В данной статье я постарался раскрыть назначение VMware Virtual SAN, принципы её работы, требования, возможности и ограничения данной системы, основные рекомендации по её проектированию.

Концепция Virtual SAN

VMware Virtual SAN (далее vSAN) представляет собой распределенную программную СХД (SDS) для организации гипер-конвергентной инфраструктуры (HCI) на базе vSphere. vSAN встроен в гипервизор ESXi и не требует развертывание дополнительных сервисов и служебных ВМ. vSAN позволяет объединить локальные носители хостов в единый пул хранения, обеспечивающий заданный уровень отказоустойчивости и предоставляющий свое пространство для всех хостов и ВМ кластера. Таким образом, мы получаем централизованное хранилище, необходимое для раскрытия всех возможностей виртуализации (технологии vSphere), без необходимости внедрения и сопровождения выделенной (традиционной) СХД.

Введение

Передо мной была поставлена задача — развернуть кластер VMware Virtual SAN 6.2 для тестирования производительности, анализа возможностей, особенностей и принципов работы гиперконвергентной программной СХД от VMware.

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

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

Данная статья будет полезна специалистам, которые впервые сталкиваются с развертыванием кластера VMware Virtual SAN 6.2. Я постарался указать подводные камни, на которые можно напороться при поднятии кластера, что позволит значительно сократить время и нервы на их обход.

Site Recovery Manager (SRM)

VMware Site Recovery Manager (SRM) это решение для обеспечения непрерывности бизнеса и аварийного восстановления, предназначенное для планирования, тестирования и восстановления ВМ (виртуальных машин) с защищаемого (основного) сайта на (резервный) сайт восстановления.

SRM предлагает 3 подхода к защите (репликации) ВМ:

Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.

Описание технологии VVOL

Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.

Представляю вашему вниманию вторую часть серии публикаций о технологиях хранения VMware vSphere. В ней будут рассмотрены новые возможности, которые стали доступны в 6 версии продукта. Из-за большого объема 2я часть будет разбита на 2 статьи: часть 2.1 с описанием технологий SPBM и VAIO (данная статья), часть 2.2 с описанием VVOL (следующая статья).

Представляю вашему вниманию первую часть серии публикаций о технологиях хранения VMware vSphere. В данной статье будут рассмотрены старые проверенные фичи, доступные еще в 4 и 5 версиях продукта.