I. Введение
Привет, это очередная статья из цикла “Сервер под задачу” :)
Здесь вы найдёте всё, что нужно знать про VMWare vSphere — ведущую платформу для виртуализации.
VMWare — это американский IT-гигант, разработчик софта для виртуализации. И да, компания благополучно ушла с рынка РФ в 2022 году. Но их продукты от этого хуже не стали, а регулярные запросы от заказчиков
подтверждают это. Спойлер: пользоваться можно даже после ухода компании.
Чтобы ответить на частые вопросы (а их много), мы решили сделать большой, длинный и необрезанный материал — перед вами самая актуальная информация по VMWare vSphere на вторую половину 2023 года.
И да, разобрать нужно over 100500 вопросов, поэтому прорабатывать будем тщательно, но без нудятины и излишних подробностей. Только самое полезное, но если у вас появятся уточняющие вопросы, то задавайте их в чате, по телефону или пишите на почту СЕРВЕР МОЛЛ. Мы общительные :)
Итак, статья подойдёт начинающим технарям, эникеям и админам со стажем (освежить память всегда полезно). Людям, далеким от технологий, тоже пойдёт, но придётся немного по ссылкам попрыгать (найдёте их в статье).
Что ж, заваривайте термос, откидывайте спинку кресла — расслабляйтесь и получайте удовольствие :)
VMware серверы
Что такое VMWare vSphere
Сфера Пузо — фотошоп, ни один хищник не пострадал от переедания.
VMWare vSphere (читается “висфер”) — это ведущая платформа для создания и управления виртуальными машинами. По сути это набор профессионального программного обеспечения (ПО) от компании VMWare. А виртуальные машины (ВМ) — это что-то вроде программной версии физических серверов.
Для использования нужна платная лицензия или ловкость рук админа, если вы понимаете, о чем я :)
Пиратство мы осуждаем! Честно-честно!
У vSphere есть 2 основные составляющие:
ESXi (от англ. "Elastic Sky X Integrated") — гипервизор 1 типа, то есть установленный сразу на сервер/хост/голое железо (Bare-Metal), без прослойки в виде серверной ОС. Гипервизор — упрощенно — это программа, создающая и управляющая ВМ, которые могут работать и храниться на различных физических серверах и системах хранения данных (СХД). Кстати, у ESXi есть и бесплатная лицензия с урезанным функционалом (нет поддержки vCenter Server и его составляющих, нет Active Directory и обновлений через vSphere Update Manager, недоступен API для резервного копирования).
vCenter Server — служба (приложение) для централизованного управления виртуализированной инфраструктурой, включая хосты ESXi и все запущенные на них ВМ. Раньше vCenter Server можно было установить на Windows (+ база данных), но в версиях vSphere 7.0 и новее эта опция не поддерживается.
Сейчас при развёртывании vCenter Server админы используют vCSA (vCenter Server Appliance) — это предварительно настроенная виртуальная машина на основе Linux, развернутая на хостах ESXi. Очень удобная штука, так как вы получаете комплексное решение со всем необходимым для работы vCenter Server: Photon OS 3.0, The vSphere authentication services, VMware vSphere Lifecycle Manager Extension, VMware vCenter Lifecycle Manager и база данных PostgreSQL
Что даёт виртуализация в целом и vSphere в частности?
Дальше в статье будут разъяснения, так что не пугайтесь, если не поняли, а пока отвечу коротко — вы сможете запускать несколько независимых друг от друга операционных систем (ОС) и приложений на одном физическом сервере (или нескольких, включая СХД), эффективно распределять и разделять ресурсы, гибко управлять ими (миграция виртуальных машин, балансировка нагрузки и высокая доступность). И всё это добро объединено в единую платформу (сферу) создания, управления и мониторинга — то есть решение комплексное.
Сфера в названии vSphere — это что-то вроде отсылки к концепции полной виртуализации, которая позволяет абстрагировать виртуализированную инфраструктуру от физического оборудования. Но, возможно, маркетологи VMWare закладывали и другие смыслы в название :)
Значение оборудования для VMWare vSphere
Здесь я вас не удивлю: для хорошей производительности, надёжности и масштабируемости (потенциал роста нагрузок без замены всего сервера) vSphere нужно правильно подбирать оборудование.
Сходу WARNING!
Развёртывание vSphere — процесс непростой. Тут понадобится архиадмин. Опытный юзер Excel — не вариант. Если вы не из тех, кто любит жизнь, то придётся изучить дополнительную информацию и провести некоторое кучу времени на настройке и тестировании. Благо у VMware много длинных FAQ’ов, обширной документации и руководств — каждому воздастся по делам его, было бы желание :)
Но не так страшен админ, как его пингуют. Есть в vSphere и вещи, облегчающие страдания. Например, админы поопытнее, понимающие в архитектуре vSphere, используют функционал vSphere Auto Deploy, чтобы автоматически разворачивать хосты ESXi в сети. То есть подключенный сервер автоматически настроится и добавится в управляемую IT-инфраструктуру — вам только пару проводов воткнуть. На сайте VMWare, разумеется, есть инструкция — велкомен.
Как сказал Тони Старк Артур Кларк: "Любая достаточно продвинутая технология неотличима от магии".
По конкретным комплектующим я пройдусь дальше в статье, дам конкретные советы по выбору, но перед этим нужно учесть кое-что чертовски важное:
Сначала определяем задачу и требования, а потом покупаем оборудование.
Вы же не будете на Toyota Supra возить мешки навоза на дачу, так? Для этого есть грузовики или пикапы. С vSphere можно решать огромный пул задач, а под каждую задачу есть своё оборудование. Серверное, конечно же. Про ПК я говорить не буду. Почему? В двух словах не объяснить, но ответ есть в другой моей статье.
А теперь перейдём к задачам и требованиям.
II. Определение задач и требований vSphere
Для каких задач подходит vSphere:
Перечислю основные сценарии использования vSphere, чаще всего их комбинируют — всё зависит от ваших требований и хотелок.
Консолидация ресурсов через vSphere
Бывает, что компания растёт, серверов становится больше, но каждый загружен лишь частично — на 30-50%, когда могут в теории на 80% (больше не стоит). То есть вы купили серверы, но не используете весь их потенциал — это называют простоем мощностей.
С помощью vSphere вы можете создать ВМ, которые будут выполнять все те же задачи, но с важным преимуществом — у вас появится общий пул ресурсов (процессор, память, хранилище), из которого будут выделяться вычислительные мощности на нужды каждой виртуалки.
Нагрузка на почтовый сервер минимальна в сезон низкой нагрузки? vSphere выделит нужный ресурс, а остальное распределит между другими ВМ, которым ресурсы нужнее. Всё это может происходить динамически — без вашего прямого участия.
Благодаря консолидации ресурсов можно уменьшить количество физических серверов и нивелировать простой мощностей. Или оставить все серверы, но решать больше задач с их помощью. Такие дела.
Динамическое масштабирование в vSphere
Выше я описал сценарий, когда мощности простаивают, но часто нагрузка на серверы изменчива, особенно в сезонных бизнесах. Бывает, что физический сервер в пиковые нагрузки “не вывозит”, и вылезают проблемы с производительностью — может дойти до отказа, как при DDoS-атаках.
Нагрузка на почтовый сервер возросла в предновогоднюю распродажу? Не проблема. Если ресурсов в кластере достаточно, то виртуальная инфраструктура выделит их почтовой виртуалке.
Итак, vSphere позволяет динамически масштабировать вычислительные ресурсы. Это означает, что вы можете увеличивать или уменьшать вычислительные мощности в реальном времени — под ваши потребности прямо сейчас. Гибко и экономит ресурсы. Но учтите, что это возможность, а не классический вариант инсталляции. Чтобы динамическое масштабирование работало, нужно и настраивать долго, и дополнительное физическое оборудование покупать.
Безопасное тестирование и развертывание приложений в vSphere
С помощью VMWare vSphere вы сможете создавать изолированные виртуальные среды для разработки, тестирования и развертывания приложений. Прежде чем выкладывать изменения в прод, можно протестировать всё на аналогичном тестовом пространстве, попробовать новый софт или установить обновления, если лень изучать патчноут.
Плюсов очень много: сокращение рисков, ускорение разработки, выявление конфликтов между версиями и приложениями. Быстро и безопасно :)
Бесперебойная работа и восстановление после сбоев в vSphere
Тестовые пространства от всех бед не спасут — проблемы бывают и на аппаратном уровне: сгоревший БП, жёсткий диск или другой компонент могут остановить работу сервера — это ночной кошмар любого админа.
Можно, конечно, дублировать комплектующие (второй БП, RAID-массив), но для полноценной отказоустойчивости и высокой доступности (High Availability) вашей IT-инфраструктуры придётся пользоваться софтом.
Например, vSphere High Availability (HA). Если сервер откажет, то виртуальные машины автоматически перезапускаются на других работающих серверах. Это же можно реализовать на распределённом (Stretched) кластере серверов — при сбое всего датацентра ВМ запустятся в резервном датацентре. Такой подход называют георезервированием, он нужен, чтобы пожар, потоп, беспилотник или другой локальный апокалипсис не остановил надолго работу сервисов.
В дополнение к vSphere HA есть функция vSphere vMotion, которая позволяет перемещать работающие ВМ между серверами без остановки работы — разве что минимальные проседания производительности и задержки пакетов возможны.
Или другой пример — vSphere Replication. Относительно недорогой в реализации, но мгновенного восстановления не даёт. Это механизм репликации на уровне хоста, который создаёт резервные копии виртуальных машин и копирует их данные на удаленные серверы или хранилища. Так вы сможете защитить информацию и восстановить работу в кратчайшие сроки после критического сбоя. Репликацию данных можно настроить на на разных уровнях: ВМ, диск или файл. И всё это с выбранной периодичностью, автоматически и по расписанию — каждые несколько минут, часов или дней.
Также есть функционал Fault Tolerance (FT). Если не углубляться, то это полный дубликат основной ВМ, который работает параллельно с ней на другом серверном оборудовании; при сбое управление и работа сразу переходят на копию — без простоев и потерь данных. Фича довольно специфична, есть ограничения по ресурсам виртуальной машины, повышенные требования к аппаратному обеспечению — но если другими средствами реализовать отказоустойчивую работу архикритичного сервиса не представляется возможным, то это станет этаким запасным парашютом для IT-инфраструктуры.
Централизованное управление в vSphere
У обычной IT-инфраструктуры есть недостаток — ей сложно управлять, если она разрастается, как борщевик. Каждый сервер нужно админить отдельно, а это большая нагрузка. Некоторые вендоры знают о проблеме и внедряют свои решения (некоторые даже интегрируются с vCenter для удобства), например, консоль Dell OpenManage, которая сильно упрощает управление серверами Dell в сети, но и это не панацея — что, если у вас серверы разных производителей?
В виртуальной инфраструктуре vSphere всё управление централизованно в приложении vCenter Server: мониторинг, контроль над ресурсами (процессоры, память), функциями и т.д. Администраторы смогут управлять виртуальными машинами, физическими серверами разных производителей, хранилищем данных, сетями, резервным копированием, восстановлением миграцией и многим другим в IT-инфраструктуре. И всё это в едином интерфейсе — наглядно и понятно.
На задачах пока остановимся, но знайте, что их значительно больше. Теперь поговорим об оценке вашей будущей среды под vSphere.
Оценка требований к вашей среде виртуализации под vSphere
Если всё делать по уму, то алгоритм получится сложный, но лучше я сразу расставлю все точки над 泳.
Вам придётся определить объём нагрузки на будущие ВМ и их характеристики, масштабируемость и уровень доступности всей IT-инфраструктуры (он же он же аптайм или SLA в разрезе сервиса, при расчётах важно учесть и TIER датацентра), учесть безопасность и интеграцию с существующими системами, провести оценку расходов (TCO и ROI) и квалификации персонала, нанять новых сотрудников и(или) обучить старых.
Каждый момент достоин отдельных статей.
Например.
Общая стоимость владения (TCO) и ожидаемая отдача от инвестиций (ROI) включают в себя не только стоимость лицензий на ПО, но и затраты на оборудование, поддержку, электроэнергию, процесс миграции, обучение персонала и так далее.
Поэтому я расскажу только про виртуальные машины и их характеристики для vSphere. Остальное останется на вашей совести или совести админа :)
Количество виртуальных машин и их характеристики
Количество ВМ можно определить, прикинув, какие из них будут заниматься приложениями (возьмут на себя серверные роли, например почтовый сервер), а какие выполнять задачи пользователей, разработчиков, тестировщиков и т.д. Плюс, если требуется высокая доступность уровня Fault Tolerance для критических приложений, то добавляем параллельно работающие ВМ на удалённых серверах и СХД. И, конечно же системные требования vSphere (гипервизор ESXi тоже кушать хочет, в пределах погрешности, но учесть это нужно).
Звучит сложно — и так оно и есть. Подсчётами должен заниматься опытный сисадмин. Если будут сложности, то опишите задачу менеджерам СЕРВЕР МОЛЛ — ребята бесплатно подберут серверное оборудование, чётко следуя ТЗ и бюджету, а КП отправят в течение часа.
Итак, сначала нужно подсчитать ваши базовые потребности — это сумма характеристик всех ВМ, учитывая их нагрузку (какие бизнес-процессы и приложения будут работать?).
УСЛОВНЫЙ ПРИМЕР для небольшой компании из 10 человек:
Рабочие станции: По виртуальному рабочему месту для каждого из 10 сотрудников. Каждая рабочая станция может иметь 2 ядра, 8 ГБ оперативной памяти и 200 ГБ дискового пространства — достаточно для простых офисных задач. Для более сложных нагрузок можно добавить ресурсов.
Файловый сервер: Это место, где будут храниться все корпоративные файлы и документы. Например, виртуальная машина с 2 ядрами, 8 ГБ оперативной памяти и 2 ТБ дискового пространства.
Сервер электронной почты: Если компания предпочитает хостить свою электронную почту локально, со своим доменом, то может потребоваться отдельный сервер для этого. Это может быть виртуальная машина с 2 ядрами, 8 ГБ оперативной памяти и 500 ГБ дискового пространства.
Сервер баз данных: Если у компании есть какие-либо бизнес-приложения, которые требуют базы данных, вы можете создать отдельную виртуальную машину для этого. Это может быть виртуальная машина с 4 ядрами, 16 ГБ оперативной памяти и 1 ТБ дискового пространства.
Далее нужно сложить вычислительные ресурсы, необходимые для одновременной работы каждой ВМ: процессор (ядра, потоки и их производительность), память (объем и скорость), хранилище (объем, скорость, резервное копирование, RAID, тип хранилища), сеть (пропускная способность, интерфейсы), безопасность (фаерволы, контроль доступа, шифрование). В моём упрощенном примере базовые потребности следующие: 28 ядер, 112 ГБ оперативной памяти и 5.5 ТБ постоянной.
Не забываем про масштабируемость. Если трафик и нагрузка на ВМ растут, например, на 20% год к году, а вы меняете/обновляете серверы раз в 3 года, то ваши базовые потребности вырастут на 1,728 (1.2 * 1.2 * 1.2) за это время.
И сверху накидываем еще 20% про запас, чтобы сервер не работал в третий год на последнем издыхании, а имел хоть какой-то запас “прочности”.
Получим формулу.
Базовые потребности * 1,728 (масштабирование на 3 года) * 1.2 (запас) = целевая производительность IT-инфраструктуры.
В моём примере:
58 ядер;
224 ГБ или более ОЗУ (здесь округление, по формуле получим 232 ГБ);
11,4 ТБ полезного дискового пространства (заходите в калькулятор и считайте, сколько дисков нужно под ваш вариант RAID-массива).
А ещё нужно посчитать сеть и ресурсы под безопасность. Но сам принцип подсчёта теперь должен быть понятен из упрощённого примера.
III. Совместимость сервера с VMWare vSphere
Итак, мы прикинули (или наши менджеры вам помогли), сколько ВМ и какая производительность серверного оборудования под них нужны, поэтому самое время выбрать вендора и конкретные модели, которые точно будут совместимы с VMWare vSphere.
Список совместимого оборудования на официальном сайте VMWare.
Первое, что стоит сделать, это свериться с рекомендациями VMWare.
WARNING!
Изучить рекомендации VMWare по совместимости оборудования (Hardware Compatibility List, HCL) — супер-важно, даже критично, начиная с 7 версии vSphere.
Раньше VMWare использовала образ на основе Linux с его драйверами, но в vSphere 7 (и старше) уже околосамостоятельная ОС, со своими драйверами — поэтому список поддерживаемого оборудования существенно сузился. Дело доходит до прошивок жёстких дисков и конкретных сетевых адаптеров. А для vSAN это ещё важнее — иначе стабильная работа (или вообще работа) не гарантируется.
VMWare не пытается усложнить жизнь строгими HCL, скорее наоборот — всеми силами не даёт аминам прострелить себе ногу некорректной конфигурацией и неправильным подбором железа.
Итак, список поддерживаемых серверных платформ есть в руководстве по совместимости VMware на сайте: https://www.vmware.com/resources/compatibility. Там вы сможете проверить своё старое оборудование или подобрать что-то новое. Но заполняйте все пункты, чтобы сработало :)
Минимальные системные требования VMWare vSphere v8.0
Помните, я говорил, что в основе vSphere лежит гипервизор ESXi? Так вот именно под его требования и нужно подстраиваться. Все версии ESXi в рамках статьи я охватить не смогу (да и смысла нет) — поддержка v6.5 и v6.7 версий окончена, v7.0 ещё побарахтается какое-то время, но тоже уйдёт в закат.
Будем смотреть вперёд — я расскажу только про последний и актуальный на середину 2023 года выпуск VMWare vSphere 8. Новая версия позволяет запускать более мощные виртуальные машины и выполнять задачи быстрее.
Всю информацию я брал с официального сайта (и перевёл для вас). Так что в достоверности можете не сомневаться :) Итак, вводных много, так что сразу к делу.
Минимальные системные требования ESXi 8:
Хост с двумя физическими ядрами процессора (и более).
Многоядерные 64-битные процессоры x86.
Включенный NX-bit для AMD или XD-bit для Intel процессоров в BIOS.
Минимум 8 ГБ физической оперативной памяти для ESXi 8. Для запуска виртуальных машин в типичных средах должно быть не менее 12 ГБ памяти.
Для поддержки 64-битных виртуальных машин на процессорах x64 нужно включить поддержку аппаратной виртуализации (Intel VT-x или AMD RVI).
Один или несколько гигабитных или более быстрых сетевых контроллеров Ethernet. vSAN — минимум 10 Гбит/c.
Загрузочный диск постоянной памяти объемом не менее 32 ГБ, например HDD, SSD или NVMe. Загрузочное устройство не должно быть общим для всех хостов ESXi.
SCSI-диск или локальный, несетевой, RAID LUN с неразделённым пространством для виртуальных машин.
Для SATA — диск, подключенный через поддерживаемые контроллеры SAS или встроенные контроллеры SATA. Диски SATA считаются удалёнными, а не локальными. По умолчанию такие диски не используются в качестве scratch-разделов, поскольку они считаются удалёнными. Прим. автора: scratch-раздел используется для хранения системных журналов, которые нужны при создании пакета поддержки. Если scratch-раздел отсутствует, системные журналы хранятся в оперативной памяти (ramdisk, блочное хранение в ОЗУ). В ситуациях с ограниченным объёмом памяти можно создать скрэтч-раздел, если его нет, но он не обязателен.
Примечание:
Вы не можете подключить устройство SATA CD-ROM к виртуальной машине на хосте ESXi. Чтобы использовать устройство SATA CD-ROM, необходимо использовать режим эмуляции IDE.
Требования к загрузке ESXi — BIOS и UEFI:
Крайне рекомендую изучить этот (https://kb.vmware.com/s/article/84233) раздел базы знаний VMware, чтобы сэкономить время и убедиться в совместимости серверной платформы.
В vSphere 8.0 поддержка устаревших BIOS (Basic Input/Output System) ограничена, поэтому лучше загружать хосты ESXi с помощью UEFI (Unified Extensible Firmware Interface) — будет меньше проблем.
UEFI — это современная замена BIOS. С его помощью можно загружать системы с жестких дисков, приводов CD-ROM или USB-носителей. vSphere Auto Deploy поддерживает сетевую загрузку и инициализацию хостов ESXi с UEFI. Если система имеет DPU (Data Processing Unit, продвинутые сетевые карты, которые разгружают основной процессор сервера), то вы можете использовать UEFI только для установки и загрузки ESXi на DPU.
ESXi может загружаться с накопителя объемом более 2 ТБ, если системная прошивка и прошивка любой используемой дополнительной платы поддерживают это.
Требования к хранилищу при установке или обновлении ESXi 8.0:
При загрузке с локального диска, SAN или iSCSI LUN нужен накопитель не менее 32 ГБ — для создания системных томов хранения, которые включают загрузочный раздел, банки загрузки и том ESX-OSData на базе VMFS-L. Том ESX-OSData — это место размещения операционной системы ESXi, он также выполняет роль традиционного раздела /scratch, раздела блокировки (locker) для VMware Tools и назначения дампа ядра.
Для быстрой установки ESXi 8.0 используйте загрузочные внешние устройства объемом от 32 ГБ.
Для обновления до ESXi 8.0 требуется загрузочное устройство объёмом не менее 8 ГБ.
Примечание:
В ESXi 8.0 том ESX-OSData считается единым разделом, а отдельные компоненты, такие как /scratch и VMware Tools, объединены в один постоянный раздел OSDATA.
Другие параметры для обеспечения наилучшей производительности установки ESXi 8.0 следующие:
Для оптимальной поддержки ESX-OSData рекомендуется использовать локальный диск объемом 128 ГБ или больше. Данный диск содержит загрузочный раздел, том ESX-OSData и VMFS хранилище данных.
Устройство, поддерживающее минимум 128 ТБ записи (Total Byte Written). Прим. автора: TBW — показатель, который указывает на общее количество байтов, которое можно записать на накопитель (обычно SSD), до достижения его предельного ресурса износа. TBW выражается в терабайтах.
Устройство, обеспечивающее скорость последовательной записи не менее 100 МБ/с. Прим. автора: скорость последовательной записи означает, что накопитель может записывать данные последовательно на свою память без разделения на отдельные блоки или файлы.
Для обеспечения надежности в случае отказа устройства рекомендуется использовать зеркальное RAID 1 хранилище. Прим. автора: RAID 1 обеспечит дублирование данных на двух накопителях для повышения защищённости и возможности восстановления в случае отказа одного из них. Плюс скорость чтения выше (при распараллеливании). Что такое RAID-массивы?
Устаревшие устройства SD и USB поддерживаются со следующими ограничениями:
Устройства SD и USB поддерживаются для разделов банка загрузки. Использование устройств SD и USB для хранения разделов ESX-OSData устаревает, лучшая практика — предоставление отдельного постоянного локального устройства с минимальным объемом 32 ГБ для хранения тома ESX-OSData. Постоянное локальное загрузочное устройство может быть флэш-памятью M.2 промышленного класса (SLC и MLC), SAS, SATA, HDD, SSD или устройством NVMe. Оптимальная ёмкость постоянных локальных устройств составляет 128 ГБ.
Если вы не обеспечите постоянное хранилище, появится сигнал тревоги, например, Secondary persistent device not found. Переместите установку на постоянное хранилище, поскольку поддержка конфигурации только для SD-карты/USB прекращается.
Вы должны использовать флэш-устройство SD, одобренное поставщиком сервера для конкретной модели сервера, на котором вы хотите установить ESXi на флэш-устройство SD. Список одобренных устройств можно найти на сайте partnerweb.vmware.com.
Обновленное руководство для сред на базе SD-карт или USB см. в статье базы знаний 85685.
Чтобы выбрать подходящее загрузочное устройство SD или USB, см. статью базы знаний 82515.
В процессе обновления до ESXi 8.0 с версий ранее 7.x происходит переразметка загрузочного устройства и объединение исходных разделов дампа ядра, locker и scratch в том ESX-OSData.
В процессе переразметки происходят следующие события:
Если пользовательское место назначения дампа ядра не настроено, то местоположение дампа ядра по умолчанию — файл в томе ESX-OSData.
Если служба syslog настроена на хранение файлов журналов на 4 ГБ VFAT scratch partition, файлы журналов в var/run/log переносятся на том ESX-OSData.
Инструменты VMware переносятся из раздела locker, и раздел стирается.
Раздел дампа ядра стирается. Файлы дампа ядра приложения, хранящиеся на нулевом разделе, удаляются.
Примечание:
Откат к более ранней версии ESXi невозможен из-за процесса переразметки загрузочного устройства. Чтобы использовать более раннюю версию ESXi после обновления до версии 8.0, необходимо создать резервную копию загрузочного устройства до обновления и восстановить загрузочное устройство ESXi из резервной копии.
Если вы используете USB-или SD-устройства для обновления, то лучше всего выделить место под ESX-OSData на доступном постоянном диске или SAN LUN. Если постоянный диск или SAN LUN недоступны, ESX-OSData автоматически создаётся на RAM-диске. Для раздела ESX-OSData можно также использовать VMFS.
После обновления, если ESX-OSData находится на RAM-диске (ramdisk) и при последующих загрузках обнаруживается новое постоянное устройство с параметром autoPartition=True, ESX-OSData автоматически создаётся на новом постоянном устройстве. ESX-OSData не перемещается между постоянными хранилищами автоматически, но вы можете вручную изменить расположение ESX-OSData на поддерживаемом хранилище.
Чтобы изменить конфигурацию /scratch, см. раздел Настройка раздела Scratch из vSphere Client.
Для настройки размера системных разделов ESXi можно использовать параметр systemMediaSize. Дополнительные сведения см. в статье базы знаний https://kb.vmware.com/s/article/81166.
При равзёртывании через Auto Deploy программа установки пытается выделить нулевую область на доступном локальном диске или хранилище данных. Если локальный диск или хранилище данных не найдены, установка заканчивается неудачно.
В средах, загружающихся с SAN или использующих Auto Deploy, том ESX-OSData для каждого хоста ESXi должен быть создан на отдельном SAN LUN.
IV. Как подобрать сервер под VMWare vSphere: железо, комплектующие
Напомню, что я не знаю вашей задачи, а потому могу дать только общие рекомендации по железу. Но вы можете описать ситуацию менеджерам СЕРВЕР МОЛЛ — ребята бесплатно проконсультируют :) Во-вторых, есть полезные рекомендации из других моих статей. Советы отлично подойдут и под vSphere.
Чтобы не повторяться, я оставлю ссылки на популярные вопросы:
С теорией разобрались — вернёмся к нашим электроовцам :)
VMWare серверы
Процессор для VMWare vSphere
Процессор, он же ЦПУ aka CPU.
Итак, в первую очередь нужно понять, какие задачи будет выполнять сервер.
Если на виртуальных машинах будут работать высокотребовательные приложения, то понадобится процессор с большим количеством ядер и/или высокой тактовой частотой. Больше ядер — больше виртуалок, больше частота — быстрее обработка данных. Если же ВМ будут прогонять через себя большой объем данных, то нужно сделать упор на кэш-память — L2 и L3.
Учитывайте поколение процессора, так как одинаковая герцовка у разных поколенией (и даже производителей) даёт разный результат.
Не забывайте про многопроцессорность. Кстати vSphere практикует посокетную модель лицензирования (и не только).
Количество процессоров | Ядер на процессор | Количество лицензий |
1 | 1-32 | 1 |
2 | 1-32 | 2 |
1 | 33-64 | 2 |
2 | 33-64 | 4 |
Получаем, что иногда выгоднее взять 1 процессор на 32 ядра, чем 2 процессора по 16 ядер. Разумеется, для тех кто покупает VMware. Ну вы поняли.
Перед покупкой сервера проверьте, сколько сокетов под CPU в нём; очень важный параметр, если ваша компания и нагрузки vSphere растут, так как можно будет масштабироваться без замены оборудования.
Если у вас целый парк серверов, то процессоры с низким TDP сэкономят большую сумму в масштабах нескольких лет, но жертвовать производительностью не стоит, так что изучайте параметры энергопотребления CPU.
И раз уж о деньгах, то скажу страшное — серверные CPU стоят дороже обычных. Но экономить на процессоре — дело неблагодарное, если вопрос 5-10 тысяч, то лучше доплатить. Скупой сисадмин платит дважды: первый раз за дешевое оборудование, второй — за сбои в системе :)
Если денег совсем впритык, то ищите золотую середину между тем, что нужно, и тем, на что есть деньги: можно посмотреть предыдущие поколения или восстановленные серверы, или пишите менеджерам СЕРВЕР МОЛЛ — ребята бесплатно подберут решение.
Чтобы больше не повторяться про бюджет в других комплектующих , закреплю это здесь: подобрать комплектующие — полдела, уложиться в бюджет — вот где кáбель зарыт.
Оперативная память для VMWare vSphere
Теперь об оперативной памяти, она же память, она же ОЗУ aka RAM.
Количество виртуальных машин, которые будут работать на сервере — это база.
Каждая ВМ требует конкретного количества ОЗУ (напомню, что VMware vSphere тоже кушает ресурсы, так что закладываем память и на это). Нужно убедиться, что в совокупности у вас будет достаточно памяти для всех планируемых виртуалок и других потребностей сервера.
Следующее — это тип нагрузки. Для сложных задач, требующих большого объема памяти (аналитика, работа с базами данных и т.п.), нужно больше золота ОЗУ. Учтите, что модули в сервере нужно ставить группами в разные каналы, чтобы обеспечить многоканальный режим работы: Single Mode, Dual Mode, Triple Mode и Flex Mode. Иногда можно получить кратную преимущество в скорости работы.
И да, часто смотрят на объем, но скорость памяти (частота) важна не меньше. Если вы поставите в сервер высокопроизводительные процессоры и медленную память, то последняя при высокой нагрузке станет бутылочным горлышком — это как чайной ложкой уголь в горн засыпать. Смотрите на характеристики CPU (пример), требования приложений и подбирайте соответствующую по скорости память.
По поколениям — в 2023 году выбирайте не ниже DDR4, если в сервере DDR3, то перед вами устаревшая модель. Ищите одинаковые модули по всем характеристикам. Поясню: если коррекция ошибок (ECC) есть в одном модуле, то она должна быть везде. Если частота — 2666 МГц, ёмкость одного модуля — 16 ГБ, а тип — RDIMM, то это должно быть у всех модулей. Вникать в этот нюанс необязательно, но знать его нужно.
Ну и куда же без масштабируемости. Если в будущем понадобится больше виртуальных машин или работа более ресурсоемких приложений, то лучше взять памяти с запасом и посмотреть, какой потолок по объему у сервера. Слоты, к слову, тоже не безграничны, в некоторых моделях серверов их больше, в некоторых меньше — зависит от позиционирования оборудования и количества процессоров.
Напоследок расскажу про ранги памяти (полезная статья коллеги). Про них обычно умалчивают — тема относительно сложная, поэтому объясню на примере из жизни.
Представьте, что у нас есть библиотека, где каждый ряд книжных полок — это ранг памяти. Каждая книга на полке — это бит информации. Библиотекарь (в моём примере это контроллер памяти) может взять только одну книгу за раз, чтобы проверить или изменить информацию в ней.
Теперь представьте, что у нас есть одноранговая (Single-Rank, SR), двухранговая (Dual-Rank, DR) и четырёхранговая (Quad-Rank, QR) память.
Одноранговая память — одна полка с книгами. Библиотекарь может взять только одну книгу за раз из этого ряда.
Двухранговая память — две полки с книгами, одна над другой. Библиотекарь всё ещё может взять только одну книгу за раз, но теперь может выбирать из двух рядов, что увеличивает его возможности. С четырёхранговой — четыре полки.
Чем больше рядов (рангов), тем больше книг (битов информации) библиотекарь может выбрать за одно обращение, хотя и забирать он может только по одной книге за раз. Это повышает эффективность использования памяти, особенно когда нам нужно работать с большим количеством информации.
Но не всё так однозначно :) Чем больше рядов, тем больше времени требуется на переключение между ними, что может немного замедлить систему.
Больше рангов — дороже память, лучше работа с большим количеством виртуалок. Если виртуалок немного, а нагрузки простые, то вам хватит и одноранговой.
Но в идеале изучить рекомендации производителя сервера или документацию VMware для оптимальных конфигураций памяти.
Такие дела. Теперь к дисковой подсистеме.
V. Хранение данных в сервере vSphere
NAS и SAN на VMWare vSphere
Локальные жесткие диски, SAN, vSAN или NAS для vSphere
Серверы — системы гибкие, так что у вас есть выбор, как всё реализовать: локальные жесткие диски или DAS, SAN (Storage Area Network), NAS (Network Attached Storage) или вовсе vSAN.
Локальные накопители (Local Storage) или DAS (Direct Attached Storage): это либо встроенные в сервер, либо подключенные к нему напрямую накопители (хранилища). Обычно это вариант по умолчанию, с которым просто работать, да и стоит относительно недорого, но есть нюансы — мобильность и масштабируемость ВМ ограничены, а некоторые функции vSphere на локальных дисках не работают вообще. Например, vMotion (перемещение ВМ между серверами без прерывания работы) или High Availability.
SAN (Storage Area Network): это сеть для передачи данных между серверами и удалёнными хранилищами (СХД, ленточные хранилища, другие серверы и т.д.). Плюс в том, что сервер воспринимает SAN как часть сервера, но у SAN нет информации о серверной ОС и файловой системе. Получаем высокую скорость работы, надёжность и низкую задержку — самый сок для виртуализации. C SAN работают функции vSphere vMotion, High Availability и Fault Tolerance. Минусы тоже есть — SAN дороже и сложнее в установке и обслуживании, чем DAS или NAS.
vSAN (Virtual Storage Area Network): vSAN — это программно-определяемое хранилище (Software-Defined Storage, SDS), интегрированное с VMware vSphere (но необязательная его часть). В vSAN локальные накопители с разных физических серверов (минимум с 2-ух, но лучше с 3-4) объединяются в общий пул. Получаем хранилище, которое отлично подходит для хранения данных виртуальных машин. У vSAN много преимуществ: гибко и просто масштабируется, легко управляется из vSphere, повышает доступность и отказоустойчивость IT-инфраструктуры. Но и минусы есть: отдельно нужно покупать лицензии (дорого, когда у вас много узлов), высокие требования (кластер серверов, обязательные быстрые SSD под кэш, сеть как минимум с 10 Гбит/c картами), нужно искать совместимое оборудование, vSAN работает на уровне гипервизора, а значит кушает ресурсы хоста.
NAS (Network Attached Storage): это устройство хранения файлов (именно файлов), по сути это специализированный сервер, к которому можно даже СХД подключить. Обычно NAS используют как datastore (хранилище файлов) для виртуальных машин. NAS можно подключать к одному или нескольким серверам по привычному Ethernet. Этот вариант проще и дешевле в установке и обслуживании, чем SAN, но поддерживает не все функции vSphere (прощай, Distributed Resource Scheduler и FT). Также производительность NAS обычно ниже, чем у SAN или локальных дисков, особенно если сеть перегружена трафиком.
Какой тип хранилища выбрать? Всё индивидуально:
Бюджет: Локальные диски и DAS обычно дешевле, чем SAN или NAS.
Производительность: У SAN выше производительность, особенно при работе с большим количеством ВМ с высокой нагрузкой.
Высокая доступность и отказоустойчивость: SAN и некоторые NAS обеспечивают функции высокой доступности и резервного копирования.
Масштабируемость: SAN и vSAN позволяют легко масштабировать хранилище по мере роста потребностей.
Так что при достаточном бюджете лучше выбирать SAN, но в малых IT-системах вполне можно использовать NAS, DAS, локальные накопители или их комбинации.
Резервное копирование и восстановление данных в vSphere
Как и всегда, нужно исходить из задач и требований. Поэтому есть минимум 3 вопроса, на которые нужно ответить:
1. Как часто делать резервные копии?
Нужно понять, какие данные важны — насколько, и как часто они изменяются.
Например, клиентская база очень важна и меняется часто. Может потребоваться резервирование каждый час. Бывают и некритичные данные, которые можно потерять без влияния на бизнес: устаревшие рекламные компании, данные о продуктах, которые больше не производятся и т.п. Их вообще можно не резервировать.
2. Как долго хранить резервные копии?
Если есть внутренний регламент или закон, то руководствуйтесь ими. Например, записи с видеокамер логично хранить не меньше недели или месяца, так как проблему можно найти позже, чем она произошла. Некоторые данные: отчетности, бухгалтерские, налоговые и кадровые документы нужно хранить в течение многих лет. Поэтому их резервирование обязательно, если не хотите штрафов.
3. Как быстро нужно восстановить данные после сбоя?
Те же налоговые документы можно восстановить хоть через неделю, но сервер, который хостил сайт, должен восстановиться как можно быстрее — час простоя бизнеса может стоить дороже самого сервера. А стратегия резервирования с быстрым восстановлением сложнее и стоит больше, так как требует дополнительного физического оборудования и настроек.
Когда ответим на эти вопросы, то можно переходить к практике. У VMWare vSphere есть встроенные и дополнительные решения для резервного копирования и восстановления:
Снимки VMware (Snapshots): Это быстрый способ создать резервную копию виртуальной машины, но это не замена полноценного резервного копирования. Снимки удобны для краткосрочного резервного копирования, например, перед внесением изменений в систему или рискованных (тестовых) операций.
VMware Data Recovery (встроено в vCenter): Это полноценное решение, которое позволяет создавать полные резервные копии виртуальных машин и хранить их в течение заданного периода времени. Немного сложнее в управлении, но оно обеспечивает более надежное и долгосрочное решение.
Сторонние решения: Veeam, Commvault Complete Backup & Recovery, Кибер Бэкап. Это сторонний софт, который предлагает продвинутые функции: дедупликация, репликация, автоматизация и многие другие.
Выбор индивидуален, но кое-что нужно сделать всем: настроить и протестировать систему резервного копирования, чтобы убедиться, что всё работает корректно и соответствует всем бизнес-требованиям.
VI. Сетевые возможности vSphere
Убедитесь в наличии достаточного количества сетевых интерфейсов vSphere
Нужно понять, сколько сетевых интерфейсов потребуется серверу VMware vSphere. Посчитать можно в несколько шагов, я бы сделал это так:
Определить типы сетевого трафика: Обычно трафик можно разделить на четыре типа: трафик управления, трафик vMotion (перемещение виртуальных машин между хостами), трафик виртуальных машин и трафик vSAN (если есть). В идеале под каждый тип трафика выделить свой сетевой интерфейс — так выше производительность, надёжность и появится изоляция. Но можно и совместить, если у вас маленькая IT-инфраструктура.
Рассчитать общую пропускную способность: Считаем, какова пропускная способность каждого сетевого интерфейса и сколько интерфейсов нужно, чтобы закрыть все требования к пропускной способности. Если мне нужна общая пропускная способность 20 Гбит/с, а один интерфейс даёт 10 Гбит/с, то у сервера должно быть минимум два таких интерфейса.
Учесть избыточность: Я всегда стараюсь иметь по крайней мере один запасной сетевой интерфейс на случай отказа основного. Убиваем двух кроликов: бесперебойная работа и обслуживание без прерывания основных процессов.
Понять, как устроена физическая сеть: Под некоторые задачи нужна изоляция и сегментация сети (повышенная безопасность, управление трафиком, изоляция ошибок, нормативные требования), а это дополнительные интерфейсы.
Иногда хватает портов “из коробки”, а иногда приходится устанавливать дополнительные сетевые платы. Для vSphere сетевые возможности сервера важны не меньше процессора или ОЗУ.
Сетевые протоколы для vSphere
Системные администраторы используют разные сетевые протоколы для разных задач, софта и оборудования — это влияет на производительность и безопасность сети. VMware vSphere поддерживает большинство стандартных сетевых протоколов, поэтому опишу их в связке с задачами:
Вот основные сетевые протоколы для vSphere:
Ethernet/IP: Это базовый сетевой протокол для передачи данных между виртуальными машинами, а также между ВМ и внешним миром. Ethernet/IP поддерживает почти любое сетевое оборудование и ПО.
TCP и UDP: Это транспортные протоколы, используемые для обмена данными между приложениями. TCP обеспечивает надежную доставку данных, а UDP — быструю, но без гарантии доставки.
HTTP, HTTPS, FTP: Это протоколы прикладного уровня, которые используют для конкретных типов взаимодействия: веб-сёрфинг или передача файлов.
iSCSI (поверх TCP/IP), NFS и FCoE: Это протоколы для подключения к удалённому хранилищу данных. Выбор зависит от конфигурации хранилища данных.
VLAN, VXLAN: Это протоколы для сегментации сети на логические подсети, которые можно разнести по разным физическим сетям, что особенно полезно в виртуализированных средах, где ВМ могут работать на разных физических серверах.
Сверяемся, что из этого поддерживает ваше оборудование и используем, либо изначально подбираем конфигурацию под ваши требования (что оптимально).
VII. Надежность и отказоустойчивость vSphere
Для полноценной отказоустойчивости и высокой надёжности нужны резервное питание и горячая замена комплектующих. Это распространённая практика для всех видов серверов (а не только для vSphere), если бизнесу критично, чтобы сервер всегда работал.
Резервирование питания — это ИБП (источники бесперебойного питания), дизельные и газовые генераторы (для больших инфраструктур) и даже разные магистральные сети питания. Можно использовать один или несколько вариантов.
Горячая замена комплектующих — это замена некоторых аппаратных комплектующих сервера без его отключения. Обычно это жесткие диски, блоки питания, сетевые карты и другие компоненты, которые могут выйти из строя. Но, например, процессор заменить без остановки не получится. Если у сервера 2 отсека под БП, то лучше занять оба и иметь минимум 1 БП про запас недалеко от сервера, чтобы быстро заменить при отказе.
Резервирование питания и горячую замену комплектующих нужно тестировать — искусственно отключайте питание или компонент под замену (до того, как на сервере заработают критически важные приложения).
Но помимо общих практик есть вещи посложнее, которые касаются именно vSphere.
Кластеризация и отказоустойчивые функции vSphere
Кластеризация — объединение нескольких серверов вместе, чтобы они работали как один. Получаем повышенную производительность и отказоустойчивость. Это нужно не всем — дорого и сложно; но под некоторые задачи нужен очень высокий уровень доступности, а тут без кластеризации никак.
Выше я упомянул vSphere Distributed Resource Scheduler (DRS) — это автоматический балансировщик нагрузки между серверами в кластере, что улучшает общую производительность и эффективность. Про vSphere High Availability (HA) тоже было, но напомню — это функция автоматического перезапуска ВМ на другом сервере в кластере, если один из серверов выходит из строя.
Чтобы эти функции работали корректно, нужно закладывать в серверы дополнительные ресурсы (процессорное время, память, пропускная способность сети). Ведь все оставшиеся ноды (другие серверы в кластере) должны полностью перенять на себя нагрузку вышедшего из строя. Поэтому, чем больше серверов в кластере, тем он устойчивее и дешевле в пересчёте на единицу.
И опять же тесты — после настройки кластеризации и отказоустойчивых функций нужно провести стресс-тесты, чтобы убедиться, что всё работает правильно, а серверы справляются с нагрузками.
VIII. Заключение
Фух. Пожалуй, опять вышла самая подробная статья в рунете — добавляйте в закладки (Ctrl + D) и через содержание возвращайтесь к нужному пункту :)
Чтобы не повторяться, вывод по статье будет коротким: подбор правильного серверного оборудования для VMware vSphere — это баланс между требованиями, бюджетом и будущими планами. Чем лучше вы понимаете свои потребности и цели, тем лучше вы сможете сделать этот выбор.
Поэтому процесс лучше делегировать опытным техническим спецам — штатным или нашим :) Опишите задачу менеджерам СЕРВЕР МОЛЛ и получите КП через час. Сэкономим ваше время и бесплатно подберём сервер(ы) под VMware vSphere.
