VMware vSAN: как к нему подходить и с чего начинать

Статья прислана читателем бложика.

Предисловие

Изначально этот текст представлял собой выборку ссылок и пояснений из подготовленной где-то перед новым, 2022 годом, презентации «почему vSAN нам не очень нужен». В апреле 2022 года старый текст пришлось перечитать, переписать и существенно расширить. По логике надо бы этот текст разбить на четыре части – теория, подготовка развертывания, тестирование, и рабочие моменты, но вряд ли я этим займусь.

Уровень материала: 50-100.

Уровень требуемого английского для чтения: IELTS 3, способность скопировать непонятный текст и вставить в пока еще доступные онлайн переводчики.

Аффтар(ТМ) выражает отдельную благодарность участникам и администрации русского сообщества https://t.me/VMwarevSAN/ за внесенные коррективы, уточнения и огромную подготовительную работу.

Оглавление

1. Что такое SDS (Software-defined storage), VMware vSAN как его представитель и что еще есть на рынке
2. Почему именно VMware vSan
3. Курсы, официальная литература и пособия по VMware vSan (сложность 50)
4. Курсы, официальная литература и пособия по VMware vSan (сложность 100(

4.1 Общие ссылки
4.2 VMware vSAN Network Design
4.3 Vmware vSAN Design Guide и Planning and Deployment
4.4 Иные ссылки
4.5 Подбор аппаратной части

5. Глобальные моменты, которые надо сразу учитывать при переходе на vSan

5.1 Мониторинг свободного места
5.2 Мониторинг состояния дисков и дисковых групп и их размеры
5.3 Резервное копирование и не только
5.4 Учет свободного места, политики хранения и особенности перестроение (ребилда) vSan и работа системы резервного копирования во время перестроения

6. Технические особенности внедрения или слово о железе

6.1 FW Зависимости
6.2 Сетевые зависимости в конфигурации
6.3 Сетевые зависимости в эксплуатации
6.4 Процедура обновления
6.5 VMware HCL и ситуация на нем

7. Организационные особенности внедрения и эксплуатации или слово о людях

1. Что такое SDS (Software-defined storage), VMware vSAN как его представитель и что еще есть на рынке

Дописано по результатам закрытого тестирования статьи, изначально этого раздела не было.

Если мы пойдем в историю развития систем хранения информации, то изначально все «хранение» представляло собой или перфокарту, или магнитную ленту. 99.95% остального придумано или в IBM, включая сами Punched card (1896), или в  AT&T (включая Bell Labs), или для военных армии и флота США (включая и микрочипы, см. Fairchild).

Хронология: в 1956 году появился первый жесткий диск (от IBM), в 1960-м появились протоколы коррекции (Reed-Solomon error recovery – разработаны для министерства обороны США), в 1970-е появились первые наработки по RAID. За много лет ситуация стала стабильной, появились и были как-то стандартизированы RAID  0/1/5/6/10/50/60, и появившиеся в 201* годах draid и triple-parity. Все было примерно  понятно  – вычисления отдельно, хранение отдельно, сети хранения (SAN) отдельно, но возник запрос на дешевое хранение не очень ценных данных(2004-2006 год, Ceph) , отвязка от вендора (замена вендорских СХД на свои – AWS / Google против A-брендов) и прочая унификация.

Ответом на запрос рынка стали программно-определяемые системы хранения, SDS (Software-defined storage) ,  гипер-конвергентные системы и миллионы тонн маркетингового мусора. Разница SDS с классической (Legacy ) СХД в том, что в старых СХД существовали специализированные чипы под расчет контрольных сумм, работу со сжатием и так далее. В новых СХД (примерно с 2015 года) вся обработка ведется только на центральном процессоре – почти точно таком же Intel, IBM, Huawei  (ARM Kunpeng) – как и в обычном сервере. В предельном случае на рынке уже есть классические СХД с возможностью запуска на нем маленькой VM.

В чем еще разница с традиционными СХД: в единичной СХД рассматриваемой единицей хранения является «диск», и для обработки отказа используется выделенный spare-диск. В новых вариантах используется размазанная по дискам свободная дисковая емкость. Резервирование полками по типу старших 3par выходит за рамки статьи. В SDS имеется определенный бардак, но можно упростить до того, что единицей учета хранения является «сервер». Raid 1 (зеркало) – 2 сервера, Raid 5 – 5 серверов (теоретически надо 3, но при 3 серверах нет разницы с triple-copy raid 1 – FTT 2), raid 6 – 6 серверов. Изучение ассортимента выходит за рамки статьи.

Решений SDS на рынке до недавнего времени много было, если честно. Это MS Storage Spaces Direct (S2D), VMware vSAN, Nutanix, Cisco HyperFlex, Huawei FusionStorage, Red Hat® Ceph® Storage, Red Hat® Gluster® .. и масса разного «иного» (EMC ScaleIO,  DataCore SANsymphony и далее).

2. Почему именно VMware vSan

У нас очень небольшая инфраструктура виртуализации – несколько  десятков 1-2 U серверов 2-10 летней давности, и часть из них давно пора заменить, как и часть СХД. Время прошло – сервера поколения HPE G5 – G6 – G7 и их ровесники – IBM System x3650 M2/M3, HS 21 и такой же давности Noname –  уже не годятся даже на лабораторные стенды, хотя  VMware ESXi 6.0 и иногда 6.5 будет работать. Та же история с СХД 2012-2015 годов – к ним уже нет ни запчастей, ни (в текущих условиях) сервиса (да и до этого он был весьма дорогой). Конечно, можно и не менять ничего – пока работает. Можно даже плакать в интернетах, что денег не дают и приходится ломать совесть и делать из желудей и листьев, А ТЫ ГОВОРИЛ ЧТО ТАК НЕЛЬЗЯ – вместо того, чтобы писать внутренние письма по оценке стоимости простоя, проводить письмо через электронный документооборот и бережно хранить подписанную докладную.

Примечание: нежелание бизнеса «просто так взять и пойти купить» без пояснительной записки про риски – интернационально. В одной американской фирме Ф. в стране С. стоит железка 2011, кажется, года – и ее никак не хотят заменить.

Что нам препятствовало до недавнего времени

– Лицензирование. VMware vSan лицензируется отдельно, стоит приличных денег, сравнимых со стоимостью start – midrange (иногда дешевле взять MSA), имеет несколько вариантов лицензирования  (Standard, Advanced, Enterprise, Enterprise Plus) – можно посмотреть таблицу сравнения.

– Обновление серверов и хранения. Глобальное обновление не планировалось, наоборот – обсуждалось уменьшение числа железных серверов путем закупки 4-5 серверов с CPU Gold (ядер побольше) и памяти 1 – 1.5 Тб на сервер, сервера на 1-2U, или переход на что-то типа Supermicro Twin или Dell PowerEdge FX2.

Почему сейчас стали рассматривать, что изменилось

Специфика обстановки в РФ и именно в нашей организации такова, что бюджетный цикл 2022-2023 необходимо планировать уже сейчас, и иметь запас и техники, и вычислительной емкости, и дисковой емкости, и ЗИП – пока это все как-то в поштучном количестве есть на рынке. Много нам и не надо – недавно полку с FC 15K 300 Gb * 24 заменили на 6 SSD.

При этом, нет никаких гарантий того, что любая продаваемая сейчас СХД будет обслуживаться в соответствие с SLA на протяжении всего жизненного цикла оборудования (5-7 лет). Вообще любая – хоть с 3 штампами «сделано в РФ» – ну не делают в РФ Intel, Эльбрус, IBM POWER8 и Huawei ARM Kunpeng. Если же мы пойдем дальше, и поинтересуемся тестами, демо-стендами и реальными возможностями «российских» СХД, то окажется, что с FC контроллерами у них зачастую «никак», да и вообще с активацией FC в РФ – сплошная боль. Ну да, есть варианты так или иначе, но в первом приближении можно считать необходимым (и давно назревшим) переход с FC 8/16 (местами и 2/4/8) на Ethernet 10/25. Надо понимать, что у того же Элтекса своего чипа тоже нет, а, Marvell / Realtek / Broadcom – ни разу не «сделаныунас», как и апрельские (04/2022) роутеры от Ростеха – где внутри Байкал (сделан на TSMC) и  Marvell 88E6390X. Marvell  – компания американская, производство – тоже TSMC.

Подводя итог: неизвестно, какие сервера, СХД и сети хранения (выбирая между FC и Ethernet), и каких брендов будут доступны к заказу «завтра», с какими SLA и какими характеристиками, но говоря сейчас FC – подразумеваем Brocade / Broadcom, и очень редко Cisco MDS, в случае Ethernet ситуация чуть легче.

Следствия:

– необходимо рассматривать переход на Ethernet  – 2-4 коммутатора всегда можно протащить в ботинках с козьими копытами, это вам не FC HPE SN8700C Director.

– необходимо рассматривать вероятный переход на программно-определяемые решения хранения – SDS (Software-defined storage), готовиться к нему – морально, организационно и повышая уровень знаний.

При выборе SDS нам (как ИТ-отделу, а не единичным маркетологам) хотелось  понимать не только аппаратные возможности решения (сколько IOPS / Gbps , каким блоком и при каком соотношении R/W можно выжать из решения), но и саму возможность сколько-то длительной эксплуатации, не в режиме черного ящика. В том числе хотелось сразу смотреть – что из этого совместимо с уже существующими системами виртуализации (скажем, Gluster + VMware – как будет?), сколько специалистов есть на рынке, какого уровня, сколько эти специалисты стоят и как сложно будет их заменить, если они уедут или заболеют ковидом-666 с печальными последствиями. Отдельно необходимо учитывать особенности эксплуатации – например, установку обновлений на систему, какие риски это несет и каков риск остановки сервиса во время процедуры обслуживания (обновления) – или даже риски сами собой, потому что память подтекала и что-то пошло не так.

Наши вводные просты – у нас есть VMware, у нас есть на него действующие лицензии (со всеми нюансами типа приостановки учетной записи) и какие-никакие (скорее никакие) кадры. У нас (как у отдела, да и как у организации) нет ни малейшего интереса в не-оплачиваемом альфа-тестировании KVM+CEPH с новыми нескучными обоями (С) – тысячи их, астро – бресто -смоленсков -гловиртов, да и нет штата, позволяющего полноценно протестировать такое решение до ввода в эксплуатацию и затем эксплуатировать такие решения.

В последний момент вспомнил про Raidix – ну, возможно, они большие молодцы. Но про это будет уже другая история.

Аналогов Huawei Open lab, VMware Hands on lab, Microsoft Hands-On Labs, Azure Lab Services, Nutanix Developer Portal – я лично не вижу на открытом рынке. Таким образом, выбор сводится к 4 вариантам выше – S2D, vSAN, Nutanix, FusionStorage.

С учетом, что у нас используется VMware – первым кандидатом в списке «на посмотреть» является  vSAN.

3. Курсы, официальная литература и пособия по VMware vSan  – сложность 50

Будет проще, если я пропущу очередной рассказ «что такое VMware vSan и в каких муках он рождался», этот вопрос достаточно подробно раскрыт два года назад (2020) году в летней академии – https://prosddc.ru/tag/vsan/, в том числе:

• Pro SDDC. VMware vSAN – Technical Overview. Part 1.
• Pro SDDC. VMware vSAN – Technical Overview. Part 2 – Availability.
• Pro SDDC. VMware vSAN – Technical Overview. Part 3 – Features.
• Pro SDDC. VMware vSAN – Technical Overview. Part 4 – Management, Operations and Monitoring.
• и лабораторной работе VMware vSAN – Getting Started /  HOL-2208-01-HCI-MYVMW-HOL  (4.5 часа).

4. Курсы, официальная литература и пособия по VMware vSan  – сложность 100

4.1 Общие ссылки

Если мы говорим про vSan, то надо начать с истории версий.

vSAN 6.7 Update 3 – вышла три года назад, vSAN 7.0 – два года назад (2020-04-02), затем (в 2020) прошли подряд четыре апдейта – 7.0u1, 7.0u1a, 7.0u1b, 7.0u1c. В марте 2021 вышел vSAN 7.0 Update 2, и актуальный релиз – vSAN 7.0 Update 3(d) вышел в марте 2022.

Можно посмотреть матрицу возможностей – vSAN Features by Version Matrix.

С учебными курсами все тоже хорошо, они есть в формате 2+3 дня. Первый курс – VMware vSAN: Plan and Deploy [V7] на 2 дня, второй – VMware vSAN: Management and Operations [V7] на три дня.  Курсы есть на Udemy – например, VMware vSAN: Deploy and Manage V7.

С официальной литературой дела обстоят, так скажем – неплохо, но есть к чему стремиться. Присутствует легкий бардак в плане различий содержаний материалов, порядка их появления и прочтения. Часть материалов различается (графикой) на сайте и в прилагаемых PDF – читать лучше и то, и другое.

Документы называются похоже, но тем не менее про разное, это VMware vSAN Network Design и Vmware vSAN Design Guide

Начало осмотра – https://core.vmware.com/vsan-plan-and-design

И отдельные прямые ссылки:

4.2 VMware vSAN Network Design

• 7.0 u1, 89 страниц.
• 7.0 u2, 89 страниц.
• 7.0 u3, 89 страниц.

В интернетах также присутствует некий 162 страничный VMWARE® VSAN™NETWORK DESIGN -vmware_vsan_network_design__vmware_noindex.pdf на 14.6 мб.

с пометкой REVISED 14 AUGUST 2020, штампом Copyright © 2019, текстом про vSAN 6.7 , но не про 7.0 и комментарием About this document: This document is not a replacement for existing vSphere Networking guidance, but more to summarize existing collateral available at https://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.htm . Хотя тоже полезный и позитивный. С официального сайта убран, почему-то.

По сетевым картам имеет смысл ознакомиться с статьей Selecting a supported network interface card for VMware vSAN и статьей Common vSAN Networking, NIC and Switch Questions.

Говоря про RDMA / ROCE, нужно упомянуть и RDG: VMware vSAN over RoCE on VMware vSphere 7.0 U2.

4.3 Vmware vSAN Design Guide и Planning and Deployment

Совершенно отдельно лежит Vmware vSAN Design Guide – 66 страниц, в тексте есть упоминание 7 Update 3, но – вот это как раз пример, что можно было сделать получше – это дописать в заголовок не две даты, а версию документа или к чему он относится.

VMware vSAN Design Guide

Или: https://core.vmware.com/sites/default/files/resource/vmware_vsan_design_guide_noindex.pdf

И отдельно лежат Planning and Deployment:

• vSAN Planning and Deployment от 2020 года
• vSAN Planning and Deployment Update 1
• vSAN Planning and Deployment Update 2
• vSAN Planning and Deployment Update 3

4.4 Иные ссылки

Надо упомянуть склад русского чата по VMware vSAN с массой иных документов и ссылок – https://telegra.ph/Osnovnye-Materialy-po-VMware-vSAN-10-05

Кроме этого, очень понимает базовому пониманию системы наличие таких статей, как:

• Understanding Data Locality in VMware vSAN
• Stripe Width Improvements in vSAN 7 U1

особенно в той части, которая касается соотношения политик хранения, страйпов и их размещения по дисковым группам в случае использования Raid 5/6 (раздел Striping and Disk Groups), да и не забывайте про дедупликацию и компрессию  – их завезли в некоторые сценарии, но смотрите внимательно – как это лицензируется Understanding vSAN Architecture: Disk Groups.

Как работает оптимизация дискового пространства (в том числе дедупликация и компрессия) vSAN Space Efficiency Technologies.

Аналогично, неплох базовый официальный трек с VMworld – vSAN 7 Track.

Рассуждая про сети и ребилд, необходимо отметить не только настройки приоритетов / резервирования в части настройки адаптеров и vSwitch, но и статью Adaptive Resync in vSAN.

Если же мы крутнем волчок и пойдем чуть глубже, то найдется и

PowerCLI Cookbook for VMware vSAN от 2019 года и по vSAN 6.7 Update 3, но все равно полезная.

Совершенно невозможно пройти мимо огромного труда VMware vSAN 6.7 U1 Deep Dive широко известных Cormac Hogan и Duncan Epping – хотя и из декабря 2018 года, но титанический труд, и буквально только что (9 мая 2022) на амазоне появился vsan 7.0u3 deep dive».

Ознакомиться с деталями по 6.7 можно тут:

• https://www.yellow-bricks.com/2018/12/12/new-book-vmware-vsan-6-7-u1-deep-dive/
• https://blogs.vmware.com/virtualblocks/2019/01/11/vspeaking-vsan67u1deepdive/

В заблокированном на территории РФ твиттере присутствует и сам Duncan Epping – https://twitter.com/duncanyb/.

Было бы грешновато не упомянуть и свежайшую статью Николая Куликова Enterprise Storage Benchmarking Guide.

При дальнейшей проработке вопроса никак нельзя пройти мимо vSAN performance evaluation checklist, но вот официальный сайзер – https://vsansizer.esp.vmware.com – уже под паролем. В сети достаточно аналогов, например, vSAN Effective Capacity.

Стоит упомянуть и о статье Optimizing Your All-NVMe vSAN Cluster (Part 1)

и Micron White Paper Micron® 7300 NVMe™ SSDs vSAN™ 6.7U3 Cluster Performance.

4.5 Подбор аппаратной части

Подбор железа можно начать с прочтения статей:

vSAN Compatibility Guide / vSAN ReadyNode – Last Updated: May 5, 2022 (свежее) – на скромные тысячу страниц, с картинками и таблицами, Supermicro vSAN ReadyNodes и в обязательном порядке знакомства с статьей What You Can (and Cannot) Change in a vSAN ReadyNode™ (52084).

Знакомства с вышеприведенным материалом достаточно для получения общего представления, насколько vSAN отличается от привычных систем хранения, в чем с ними схож, и откуда начинать расчет «сколько нам надо».

5. Глобальные моменты, которые надо сразу учитывать при переходе на vSan

Конечно, это тема для отдельной большой статьи, но за последние 5-7 лет в области, назовем ее так, публичного сообщества ИТ в РФ, случился качественный переход. ИТ в РФ и так много лет стояли на краю пропасти, но сделали шаг вперед, и теперь люди, не способные прочитать за раз больше 3 страниц, собраны на одном сайте –но статья пишется «для себя и другого сайта».

5.1 Мониторинг свободного места

С свободным местом, а точнее с его мониторингом, в ряде организаций не всегда все хорошо, случаются перегибы на местах. Случаются и тонкие диски, ВНЕЗАПНО выросшие до своих размеров, и не убранные цепочки бекапов – снапшотов. Вторым славятся все системы резервного копирования, особенно не находящиеся под ежедневным контролем. В моей практике попадался зависший на 4 месяца снапшот, потому что в кассетном пуле именно под эту VM кончились пустые кассеты, а в общественных рассказах случались и висящие по году цепочки без консолидации. У коллег случались и случаи «место кончилось на СХД совсем, а предупреждения мы отключили». Как пишут коллеги:

Есть два пути к production down – число одновременных сбоев превысило FTT и кончилось место. При этом, место может кончится на отдельном диске, т.е. вероятен (и это случается) сценарий, когда заполнение datastore ~90% процентов, но отдельные ВМ встают в suspend. Такое происходит при резком росте/всплеске емкости вызванным активной записью и/или ребилдом.

Поэтому мониторинг свободного места включая (datastore utilization after host failure в health check) – залог спокойного существования.

С vSAN причина для повышенного беспокойства следующая: диски VM по умолчанию тонкие, и к ним можно задать процент резервирования. Однако, трогать эти настройки без очень, очень существенной необходимости НЕ надо (там и дедуп отключается, и вообще не самый лучший сценарий использования), но знать про это необходимо. Детально нужно почитать, начав отсюда: First off, vSAN has it’s own control of space reservation. the Object Space Reservation policy OSR=100% (Thick) or OSR=0% (Thin). This is used in cases where you want to reserve capacity and prevent allocations that would allow you to run out of space on the cluster.

5.2 Мониторинг состояния дисков и дисковых групп и их размеры.

Калькулятор (сайзер) показывает, что иногда лучше использовать дисковые группы (диски хранения плюс диск кеша) поменьше, это позволяет ценой потери какого-то объема получить более стабильную конфигурация в части перестроения, то есть на ребилде. Плюс, R5/R6 разбивает объект «диск виртуальной машины» на страйпы – а дальше смотрите выше упомянутый Understanding Data Locality in VMware vSAN

Кроме этого, есть еще неочевидные плюсы и особенности, а именно:

Каждая дисковая группа отдельный и независимый процесс на хосте (LSOM). При этом современные SSD легко утилизируют производительность обработки, что приводит к тому, что с точки зрения Max IOPS разницы между условным Optane и MU (Mixed Use) NVMe практически нету (хотя видна разница по latency особенно 95/99 персентиль). Поэтому две дисковых группы с MU SSD будет всегда быстрее, чем одна дисковая группа с WI (Write-Intensive) SSD практически в два раза. Третья добавит еще +20-30%. Далее все уже не так однозначно, потому что, во-первых, LSOM(Local Log-Structured Object Manager) в vSAN 7+ после оптимизации достаточно быстрый и поэтому bottleneck перемещается выше по стеку (обычно DOM Client) и тогда разницы нет, или она заметно меньше + видна только под некоторым типом нагрузки, которая не сильно грузит CPU LSOM/DOM, но сильно грузит диски типа SeqWrite.

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

Примечание к последнему пункту: если вы внимательно прочитали документацию выше, то помните, что в vSAN два типа объектов в дисковой группе (в общем случае) – кеш (cache device) и storage (capacity devices). При выходе из строя кеша – будет перестраиваться не кеш, а вся дисковая группа.

5.3 Резервное копирование и не только

Необходимое отступление-1, или опять дадим слово коллегам:

С одной стороны работы бекапа (VADP) никак не связана с vSAN ибо осуществляется выше по стеку и любой СРК, которая работает со сферой будет работать с vSAN, но при этом необходимо почитать рекомендации вендора для оптимизации (например, размещать прокси на кластере, чтобы работал HotAdd способ, а не другие)

С другой, все с резервным копированием всегда все не так просто за пределами «только стека». Много лет до людей доходило, что есть:

– и бекап средствами приложения (обычно даже работает и даже обеспечивает целостность данных – хотя и не всегда, в postgre была бага с большими таблицами – BUG #15333: pg_dump  pg_dump: could not stat file ..  Unknown error ),

– и появившийся в связи с развитием виртуализации понятие «резервная копия всей виртуальной машины», вместе с массой проблем с Changed Block Tracking (CBT), о чем можно почитать тут

https://www.ibm.com/support/pages/backup-vmware-vms-can-be-corrupted-and-thus-not-restorable-if-snapshot-exists-when-cbt-enabled

и тут https://kb.vmware.com/s/article/1020128

– и связанное обычно с VM понятие Application consistent backup,

– и резервная копия сразу тома (LUN) / группы томов (LUN Consistency Group) / Группы томов в репликации в метро-кластере (HyperMetro Consistency Group).

Сложность ситуации в том, что где-то до середины 200х приложения (x86) не понимали, что такое MS Volume Shadow Copy Service (VSS) и что с ним делать, и что делать по команде от сервиса. Диск и операционная система понимали, приложение – ой как не всегда. Ситуация менялась, и в какой-то момент VSS в основном стало обеспечивать целостность данных приложения при создании снимка средствами и методами операционной системы, но только под Windows. В случае Oracle все эти ухищрения были не очень нужны, и местами даже вредны, RTFM Oracle Recovery Manager (RMAN). В случае Linux .. конечно, были скрипты. В 2018 году Microsoft написали свой Application consistent backup for Linux VMs, о чем можно почитать тут –

https://azure.microsoft.com/en-us/blog/application-consistent-backup-for-linux-vms-using-azure-backup-is-generally-available/

Или, оказывается, год назад (2 июня 2021) Мамонт написал хорошую статью, но зачем-то для убогого сайта, никогда бы не подумал там искать:

https://habr.com/ru/company/veeam/blog/560534/ с продолжением тут – уже про Linux https://habr.com/ru/company/veeam/blog/563056/

В какой-то момент оказалось, что проще снимать бекап не с снапшота VM, а по цепочке событий, дедка за репку, агент приложения СРК(системы резервного копирования) вызывает соответствующий интерфейс (или метод? Или сервис?) в ОС, потом СРК создает снапшот VM (сразу Application consistent), потом СРК вызывает создание снапшот на СХД (системе хранения данных), и уже с СХД забираются данные в СРК (D2D, D2T, D2D2T).

Одновременно оказалось, что в случае СХД можно найти еще несколько полезных применений снапшотам – не только их копировать на медленное хранилище «снапшот как бекап» – но и быстро презентовать этот снапшот каким-то еще системам – разного рода dev/stage, аналитике и так далее. Можно такие задачи решать и средствами СРК (с учетом времени на бекап и затем восстановление в dev/stage), и средствами СХД. Средствами СХД быстрее, но растут требования к кадрам – необходимо не только сделать снапшот и презентацию LUN,  но и обработать данные на нем для доступности данных – VM в dev/stage.

Однако, если мы переходим на vSAN, функций снапшота всего LUN / группы LUN у нас уже не будет, и, если мы хотим делать бекапы (например MS SQL) действительно часто и регулярно, но без постоянного снапшота и консолидации боевых баз VM MS SQL, то нам придется читать не только рассказы «как круто майнить на продуктиве ,если ИБ не смотрит» –  чему посвящено целое сообщество в телеграмме, но и читать документацию по Log Shipping and Replication (SQL Server).

То есть: При подготовке перехода необходимо рассматривать не только систему виртуализации «в себе», но и связанные системы, работающие и с СРК, и в связи с имеющимися связками СРК/СХД/dev/stage/etc.

Вдогон: разумеется, нужно знать, есть ли у вас VAAI и зачем вы его внедряли. Или не вы.

5.4 Учет свободного места, политики хранения и особенности перестроение (ребилда) vSan и работа системы резервного копирования во время перестроения

Свободное место в vSan считается довольно специфичным образом, но вы с этим еще отдельно столкнетесь.

Особенности перестроения vSan неразрывно связаны с failures to tolerate (FTT)  – таблица «что это такое.

и прочитать про работу Storage policy /  force provisioning и сценарии использования (включать его НЕ надо) можно в официальной документации.

6. Технические особенности внедрения или слово о железе

6.1 FW Зависимости

Прошивко-, драйверо-, HCL-зависимость.

Необходимо проверять и перепроверять версии FW от уровня дисков до уровня сетевых карт. Все оборудование должно присутствовать в HCL и FW устройств должны соответствовать версиям в HCL:

Для SAS/SATA – не ниже указанной в HCL версии

Для контроллеров и NVMe – в точности соответствовать

Для сетевых карт – не знаю, лучше подстраховаться. Ссылка на статью Selecting a supported network interface card for VMware vSAN? – выше.

Собрать из желудей и шишек не получится (точнее, придется использовать или глинку, или пластилин или еще что-то по ситуации), но это для всех SDS так, и для S2D, и для остальных.

6.2 Сетевые зависимости в конфигурации

В результате ухода от FC в сторону Ethernet, вы неминуемо столкнетесь с сетевыми религиями вида legacy – это любимая слишком многими, и порой исключительно по причинам «так делали еще деды и про это говорили на курсах», вариациями LAG / MLAG / LACP / Etherchannel / Teaming  / Son of perdition / Little horn / Most unclean – я, конечно, порой скучаю по старым именам, но давайте, пожалуйста, уже без вот этого, не искушайте без нужды!  Лучше вносите поправки в сетевые конфигурации – у нас не работает все, что написано.

Делать так или нет – решайте и обсуждайте сразу. В документации есть отдельный раздел за/против тех или иных конфигураций, ссылки вынесены выше.

Если начинается разговор про 25G + ROCE  – это отдельно описано в документации (плюс Ссылка на статью RDG: VMware vSAN over RoCE on VMware vSphere 7.0 U2. вынесена в общий список ссылок), но RoCE v2 – это UDP, и за ним сразу тянется длинный хвост того, о чем не любят говорить, думать и читать заранее – lossless ethernet, Data center bridging (DCB) и так далее. Рядом же идет (опять же!!) описанное в документации резервирование полосы под работу vSAN, и так далее, и тому подобное. Необходимо сразу менять процедуры тестирования конфигурации, скорее всего, придется все же познакомиться с ПМИ / ПСИ / ГОСТ РД 50-34.698-90. И помните, vSAN НЕ iSCSI. Подробности «что это» будут ниже.

И да, RDMA / RoCE не работает из коробки на Cisco Nexus / Arista / Mellanox.

6.3 Сетевые зависимости в эксплуатации

Если исторически отделы были как-то разделены внутри себя на виртуализацию, сетевиков, а N и F порты администрировали разные люди – то в один момент времени ломалось что-то одно, одна фабрика или один порт. Бывало иначе – разваливался MLAG, Nexus/ vPC/ Virtual Connect превращался в тыкву или даже кирпич, но не часто. В случае vSAN сеть критична, и обновляемая без предупреждений сетевая часть в vSAN может доставить радости, особенно если случайно так выйдет, что реально работало не два порта, а один, и так вышло что именно он и лег, потащив за собой статус absent и последующие внеплановые ребилды, так что придется что-то делать с процессами именно совместной эксплуатации. Этот момент часто забываем, и находится на стыке и сетей и организации совместной работы. В крупных организациях такие работы согласуют по 10 человек и хорошо если за месяц, и если на этот месяц не приходится Новый год, 9 мая, выступления отдельных лиц и так далее, о чем все работники разного рода девяток / десяток / линксов и прочих ЦПД/ЛАЦ, и причастных к Core / BRAS отлично знают.

6.4 Процедура обновления

Пока у вас было хранение отдельно – сети передачи данных отдельно – вычисление и виртуализация отдельно, то все сразу сломать было достаточно сложно. Можно, но сложно – скажем, накатить прошивку без предварительных проверки , и иногда бывают  такие случаи, что надо было ставить внеплановые патчи / Debug (D) Release или откатываться.  Но сложно. В случае vSAN у вас повышаются требования к кадрам. Требуется не только прожимание далее-далее-готово, но понимание что они делают, зачем и в какой последовательности. Мало кто любит dev /stage/prod, ведь можно просто запустить установку патча. Это так легко, и читать длинные и нудные release notes не нужно. В случае vSAN можно, вообще не думая, раскатать HPE SPP и потом удивляться – ой а что это сломалось. Эта ошибка эксплуатации скорее тоже находится на стыке технических и организационных проблем, когда на интервью проверяют, умеет ли человек говорить нужные слова, но не проверяют, умеет ли он вообще читать. Практика последнего (2022) года показывает, что растет доля людей, которые не просто не умеют читать самостоятельно, но и отказываются это делать – ведь есть же сообщество, которое обязано помочь – быстро, бесплатно и качественно. На выходе ужас – люди, которые не просто не читают, но и тиражируют ошибки и методологии прошлых лет, и за год не могут прочитать 2-3 абзаца текста.

6.5 VMware HCL и ситуация на нем

Кроме выше упомянутого vSAN ReadyNode – есть и HCL, hardware compatibility guide  / VMware Compatibility Guide, но к нему есть масса вопросов. Например, и это только один из вопросов, у Mellanox есть карты серии ConnectX®

-4 Lx EN Card, список которых приведен в пдф на стр.4, Card Portfolio & Ordering Information.

Берем первую из 25G карт, MCX4111A-ACAT, вводим в поиск и получаем Found 7 results for “MCX4111A-ACAT” – из которых первая MCX512A-ACAT (и какая тут связь?), вторая MCX4111A-ACU – карт с такой маркировкой в выше приведенном документе нет, есть MCX4111A-ACUT.

Может так только с сетями, подумаешь 1 буква? Нет, та же ситуация много с чем еще, с пояснением: Footnotes: The device PID string (model) is truncated in ESXi. Please use both model number and firmware version when trying to identify the device. When in doubt, please consult with the hardware provider.

Как сообщают коллеги:

Главный и единственно однозначный показатель – Hw id. Если он совпадает у вас с hcl, то все норм. Если нет, то девайс левый и не поддерживаемый.

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

7. Организационные особенности внедрения и эксплуатации или слово о людях

Запустить ESXi + VCenter + vSAN методом далее-далее на почти любом железе возможно, и оно даже будет работать (скорее всего). Можно:

– не думать про планирование таких вещей как проверка и настройка NTP (и получить проблемы с vMotion),

– игнорировать ошибку System logs are stored on non-persistent storage (2032823),

– не описывать ни настройки в профилях хостов, ни задачи / разделение VLAN, ни загрузку (откуда грузимся и почему так),

– игнорировать возможность один раз потратить два часа и написать простейший скрипт конфигурации Standard vSwitch и получить 10 комбинаций VLAN на 5 хостов,

– вообще не вести документацию, и спустя год-два получить ошибку вида «невозможно загрузить систему, старый админ уволился, документации нет, ничего нет, НИГРУЗИЦА, откуда грузилось – неизвестно».

Это все из практики аудита от коллег за последние два года и из запросов в группу, а не какие-то «исключительные и вымышленные случаи».

В первую очередь начинайте внедрение vSAN с подготовки мониторинга, проверки состояния сети и документации:

– начиная от служебной записки «зачем это нам»,

и заканчивая, но не ограничиваясь:

– написанием стандартной модели угроз (кончилось электричество, вышел из строя диск, вышел из строя весь сервер, в выделенную сеть управления пробрался внутренний любитель майнеров и развернул там вирус, вышел из строя коммутатор и так далее);

– подготовкой программы и методики испытаний (ПМИ);

– проведением приемо-сдаточных испытаний (ПСИ);

– новых BCP (business continuity plan);

– новых DRP (disaster recovery plan);

– новых проблем по части ИБ, ОСОБЕННО если у вас любители vGate.

Техническая часть описана, и техническую часть запустить легче, чем поменять настройки в головах – что это нужно, что без этого может случиться очень длинный и неприятный простой. Придется учиться делать хорошо, а не как обычно, читать документацию ДО нажимания любых кнопок, читать документацию по известным параметрам, и перечитывать по слабо известным – например по настройке Storage policy / force provisioning. Детальная статья по использованию force provisioning будет размещена в следующей части.

Дадим слово коллегам, не понаслышке знакомым с рисками эксплуатации –

Ещё один важный момент касательно ёмкости, что всплески могут быть связаны с изменением политик. И тут можно стрельнуть себе в ногу (хотя заметно сложнее, начиная с 6.7u3, когда vsan резервирует себе жёстко служебное место + делает операции ребилда маленькими пачками + смотрит, а сколько есть ли вообще место, чтобы его закончить, и если нет, то не делает).

Раньше, если изменить storage policy всех объектов на datastore (поменяв, например, default storage policy), то можно практически гарантированно забить все на 100% по ёмкости и встать. Это становится особенно опасным в случае, когда мы вдруг обнаруживает, что места практически нет, и нам не приходит в голову ничего лучше, чем перестроить с ftt1 mirror (x2 по ёмкости) на r5 (1.33), но вместо улучшения ситуации мы наблюдаем новый всплеск и массовый ребилд. Это связано с тем, что vsan СНАЧАЛА создаёт новый r5 raid-tree, а только потом убивает данные в зеркале. И это логично, ибо в нормальных случаях мы не хотим, чтобы изменение storage policy приводило к снижению уровня доступности, и, следовательно, потенциальным рискам. См. https://www.vmgu.ru/news/vmware-vsan-change-storage-policy-for-vm-and-rebuild-resync