OPEN DEMO BASIS DYNAMIX ENTERPRISE 4.6. ОТВЕТЫ НА ВОПРОСЫ
«Базис»Платформа: редакции, обновления, установка
Можно ли развернуть узлы управления как ВМ на тех же трёх физических узлах? Выделять отдельные серверы накладно.
Да, развёртывание управляющих узлов в виде ВМ поддерживается. Предусмотрено два варианта: (1) совмещение ролей управляющего и вычислительного узла на одном физическом сервере (не менее трёх серверов); (2) размещение управляющих узлов в виде виртуальных машин на вычислительных узлах.
Будет ли у этой версии сертификация ФСТЭК?
Версия Basis Dynamix Ent с связке с продуктом Basis Virtual Security имеет действующий сертификат ФСТЭК.
Как будет проходить обновление на новые версии DX? Планируется ли downtime систем?
Простой пользовательских сервисов, выполняющихся на виртуальных машинах, при обновлении платформы не предусматривается — сервисы продолжают функционировать в штатном режиме. Интерфейс управления (веб-портал) становится временно недоступным на период обновления управляющих узлов. Платформа сохраняет устойчивость при отключении управляющих узлов кластера.
Какие версии DX можно обновить до 4.6? Какие ОС поддерживает DX 4.6 и каковы планы по поддержке ОС, отличных от vCore?
Обновление с версий 4.4 до 4.6 поддерживается напрямую. Для более ранних версий необходим пошаговый переход. Поддержка операционных систем AstraLinux, Альт, Ubuntu не прекращается, однако новые функциональные возможности (интерактивный инсталлятор, VGPU) будут реализованы только для vCore.
Когда будет возможен переход на vCore с версии 4.3+ без простоя? Когда появится полноценная поддержка BDE и BVP?
Переход на vCore без простоя сервисов возможен при условии поэтапного освобождения и переинсталляции вычислительных узлов на vCore.
На сколько лет выпускаются самоподписанные сертификаты?
Стандартный срок действия — 10 лет. Ограничение обусловлено политикой современных веб-браузеров (Chrome, Firefox, Safari), которые выводят предупреждение о потенциальной невалидности сертификата при сроке действия свыше 10 лет. В контексте Kubernetes на управляющих узлах срок действия является настраиваемым параметром — допускается использование как автоматически ротируемых самоподписанных сертификатов, так и сертификатов, выпущенных корпоративным удостоверяющим центром.
Для чего нужен режим ВМ «только для чтения»?
Режим «только для чтения» (ComputeChangedOnly) предназначен преимущественно для защиты виртуальных контроллеров — управляющих узлов, функционирующих в виде ВМ. Режим блокирует выполнение следующих операций: перезагрузка, остановка, миграция, операции с дисками ВМ. Управление режимом доступно исключительно администратору платформы. Дополнительно режим может применяться для защиты критичных сервисов (баз данных и иных ответственных нагрузок).
Где найти официальную документацию об изменениях в релизе и выявленных ошибках?
Полный перечень изменений публикуется в официальных release notes к соответствующей версии продукта.
Есть ли разница в работе контроллеров: отдельно от CPU-хостов, на одном хосте с CPU или в виде ВМ?
При развёртывании на физических серверах (совмещение ролей) управляемость несколько ниже, поскольку ПО установлено непосредственно на оборудование. При развёртывании в виде ВМ достигается дополнительное преимущество по отказоустойчивости за счёт применения правил DRS и Anti-Affinity для виртуальных машин управляющих узлов.
Управляющие ноды в виде ВМ размещаются на любых типах СХД (FC, iSCSI, NVMe) или только на локальных?
Управляющие узлы в виде ВМ могут размещаться на любых поддерживаемых типах систем хранения данных: FC, iSCSI, NVMe, локальные диски.
Появилась ли возможность (скрипт/функция) миграции на Dynamix с импортных систем виртуализации?
Для миграции ВМ с импортных платформ виртуализации используется продукт — «Базис.Migration Assistant», обеспечивающий live-миграцию и конвертацию виртуальных машин из Vmware, vSphere и других систем виртуализации. В платформе DXE запланирована реализация импорта дисков ВМ через графический интерфейс.
Как совмещать контроллеры и BVS: какой порядок установки — сначала DX, потом BVS?
Для получения корректного порядка установки и настройки совместного развёртывания DX и BVS рекомендуется обратиться к официальной документации по соответствующим продуктам. Общий подход, сначала устанавливаем DX, затем BVS.
Появилась ли возможность (скрипт/функция) миграции на Dynamix с импортных систем виртуализации?
Для миграции ВМ с импортных платформ виртуализации используется продукт — «Базис.Migration Assistant», обеспечивающий live-миграцию и конвертацию виртуальных машин из Vmware, vSphere и других систем виртуализации. В платформе DXE запланирована реализация импорта дисков ВМ через графический интерфейс.
В AstraLinux нет привычного пакета Watchdog — какие рекомендации?
В платформе используется эмулируемое устройство Intel 6300ESB (PCIe). Для активации watchdog в гостевой ОС необходимо установить соответствующий пакет и сконфигурировать сервис watchdog (сторожевой таймер) в соответствии с рекомендацией производителя Операционной Системы (ОС)
Какова поддержка AstraLinux в версиях DX 4.8 и далее для новых инсталляций?
Для новых инсталляций на AstraLinux базовая функциональность платформы сохраняется в полном объёме.
Есть ли калькулятор для гиперконвергентной инсталляции?
Отдельный публичный калькулятор для гиперконвергентной инсталляции в настоящий момент отсутствует. Расчёт конфигурации производится на этапе проектирования специалистами компании Базис и выполняется комплексно, исходя из требуемых характеристик нагрузки: количества и типа виртуальных машин, профиля потребления CPU и памяти, требований к производительности дисковых операций (IOPS) и ёмкости хранения, а также схемы резервирования и отказоустойчивости.
СХД, диски и снапшоты
Когда будет совмещён функционал SCSI и iSCSI в одном Shared SEP?
Сейчас приходится делить ноды из-за ограничения «1 нода = 1 SEP». В версии DXE 4.6 параметр protocol вынесен из SEP на уровень пула хранения и является его атрибутом. Таким образом, для одного SEP типа Shared возможно подключение нескольких пулов с различными протоколами: SCSI, iSCSI, NVMe.
NVMe-oF работает только для реализации «Ядро» или можно подключить другие СХД с поддержкой протокола (например, Ceph)?
В платформу добавлена поддержка NVMe over TCP для подключения к СХД с типом Shared и к СХД Tatlin в варианте с драйвером. Допускается подключение любых СХД, поддерживающих протокол NVMe over TCP.
Насколько вырастет производительность при использовании NVMe over TCP вместо iSCSI?
NVMe over TCP позиционируется как полноценная замена Fiber Channel для высоконагруженных архитектур, обеспечивая существенно более высокую производительность по сравнению с iSCSI за счёт оптимизации протокола, меньшей задержки (latency) и большего количества IOPS. Конкретные значения прироста производительности зависят от сценария использования и конфигурации оборудования.
Планируется ли поддержка NVMe over RoCE?
На текущий момент данное направление в дорожной карте отсутствует.
Когда будут доступны тонкие (thin) диски на хранилище типа Shared SEP?
Функциональность тонких дисков для SEP типа Shared будет доступна, начиная с версии 4.7.
В какой версии снапшот перестанет требовать ×2 места на СХД (Shared LVM) и будет занимать ~0, постепенно набирая изменения?
Данная функциональность будет доступна, начиная с релиза 4.7. Реализована возможность выбора тонкого пула для размещения снапшота, что позволяет снапшоту занимать исключительно фактический объём изменений без предварительного резервирования дополнительного пространства.
Поддерживаются ли связанные клоны для СХД, подключённой по FC как блочное устройство?
Да, поддерживаются. Протоколы Fiber Channel, iSCSI и прочие являются способами доставки блочных устройств — функциональность связанных клонов идентична для всех указанных протоколов.
Какие изменения произошли в процессе создания дисков?
Создание дисков в версиях DX 4.4 и 4.6 не имеет значимых изменений. То есть API-вызов, используемый в 4.4, будет работать в 4.6. Но для создания дисков в 4.6 появилось два дополнительных параметра: 1. cache тип — string описание — cache mode of disk может иметь значения: "none", "writethrough" По умолчанию значение — "none". 2. blkdiscard тип — boolean описание — Allow disk unmap: true for unmap, false for ignore. По умолчанию — false. Так как оба параметра имеют значения по умолчанию, они не являются обязательными при вызове API-метода /disks/create.
В описании SEP для Tatlin есть параметр jobs_concurrency — «количество одновременно выполняемых задач на СХД». О каких задачах идёт речь?
Параметр определяет количество одновременно направляемых запросов к API СХД Tatlin (не количество одновременно выполняемых задач на СХД). Значение по умолчанию — 1, что является наиболее безопасной настройкой. Параметр может быть изменён администратором.
Появилась ли возможность смотреть метрики по каждому отдельному диску, а не агрегацию по дискам ВМ? Какие метрики доступны?
В текущей версии веб-интерфейса данная возможность отсутствует. Расширение функциональности мониторинга, включая отображение метрик на уровне отдельных дисков, запланировано в рамках работ по развитию веб-интерфейса платформы.
Образы, зоны и политики хранения
Какова ситуация с виртуальными образами в 4.6? Меняется логика работы с ними в части storage policy — как теперь работать?
Функциональность образов претерпела изменения в части применения политик хранения (storage policy). Политика хранения стала обязательным параметром при создании диска, ВМ, образа, группы в составе базовой службы, кластера Kubernetes, а также ряда операций, связанных с указанными сущностями. Детальное описание технологий и принципов работы с ними можно найти в официальной документации к продукту.
Как изменить образ ВМ, из которого она развёрнута? Зачем привязка образа сделана через image/update?
В версии 4.6+ изменён механизм привязки образа к ВМ. В модели диска ВМ присутствует поле image_id, которое заполняется при создании ВМ из образа. Для управления виртуальными образами используется API cloudapi/image/createVirtual и cloudapi/image/get, где virtual image выступает прокси-объектом с полем linkTo, указывающим на целевой образ. Это позволяет разделить эталонный образ (template image) и его привязку к конкретному аккаунту и диску ВМ, а также управлять доступом к образам на уровне аккаунтов через механизм sharedWith. Изменение образа существующей ВМ возможно через API update с корректировкой image_id диска.
Нужна ли вторая СХД для мультиобраза? Работает ли мультиобраз только в рамках одного SEP?
Вторая СХД не является обязательным условием для использования мультиобраза. Мультиобраз — это объект, который ссылается на идентичные образы, размещённые на разных пулах хранения; принадлежат ли эти пулы одной или разным СХД — значения не имеет. Таким образом, мультиобраз может работать как в рамках одного SEP (объединяя образы из разных пулов), так и ссылаться на образы, распределённые по пулам нескольких разных SEP. Обратите внимание на ограничения по типам SEP: в версии DX 4.6 мультиобраз поддерживается только для SEP типа Local. Поддержка SEP типа Shared ожидается в версии 4.7.
Как работать с зонами на примере образов, SEP, ExtNet и аккаунтов?
Доступные для создания объекты в аккаунте определяются тем, какие зоны к нему добавлены. Например, если для аккаунта acc1 задана только зона default, то при создании виртуальной машины в ресурсной группе этого аккаунта выбрать зону intelcpu_zone будет невозможно.
При необходимости к аккаунту можно привязать несколько зон. Возможные сценарии использования зон:
- Разделение вычислительных узлов по контурам — тестовый, продуктивный и контур управления.
- Группировка узлов по поколениям процессоров
Как устроены политики хранения (storage policy) и как их сгруппировать?
Политика хранения (объект «Storage policy») — объект для группировки пулов хранения, в том числе из разных СХД, с возможностью ограничить IOPS создаваемых дисков на пулах хранения. Предполагается группировка в политике хранения пулов с одним типом дисков, например HDD или SSD. Политика хранения — обязательный параметр при создании диска, ВМ, образа, группы в составе базовой службы, кластера Kubernetes и ряда операций, связанных с данными сущностями. Политики хранения могут применяться к аккаунтам и ресурсным группам. Например, у нас есть несколько подключений к СХД (SEP):
1. SEP Shared — с HDD-дисками.
2. SEP TATLIN — в режиме драйвера с SSD-дисками.
3. SEP HITACHI — в режиме драйвера с SSD-дисками.
4. SEP Local — с подключенными локальными SSD-дисками ВУ.
Из этого набора мы можем сделать, к примеру, 3 политики:
1. Policy_HDD — добавив в неё SEP Shared и все его пулы.
2. Policy_SSD — добавив в неё SEP TATLIN и SEP HITACHI, все их пулы (ну или конкретные пулы, как нам больше нравится).
3. Policy_Local — добавив в неё SEP Local и все его пулы.
Для каждой политики задается ограничение в количестве IOPS, доступное для объектов, ее использующих.
Как назначить политики хранения на аккаунт и ресурсную группу?
Лимиты по IOPS и объёму. Чтобы политики можно было использовать:
1. В руководстве администратора DXE присутствует разделы 9.1.3.5 и 9.2.3.4 по управлению политиками хранения аккаунта и ресурсной группы соответственно.
2. Неообходимо назначить политики хранения аккаунта.
3. Неообходимо назначить политики на РГ (будут доступны те, что назначены на аккаунт).
Соответственно, любое взаимодействие с СХД (создание ВМ и, как результат, создание дисков, загрузка образа и т. п.) требует указать, куда располагать данные. А список доступных пулов для расположения определяется доступными политиками в той РГ, где создается объект.
Хочу отметить, что при назначении политики для аккаунта или РГ можно указать лимит в ГБ (по умолчанию -1 — без лимита). Если такой лимит задать, то использование этой политики будет лимитировано по суммарному объему дисков в том аккаунте или РГ, где лимиты заданы.
DRS, эвакуация и мониторинг
DRS мониторит в первую очередь нагрузку на узлах, а не качество предоставления ресурсов конечным ВМ?
Механизм DRS осуществляет мониторинг загруженности виртуальных машин, а не гипервизоров. Сбор метрик выполняется посредством встроенных компонентов мониторинга платформы. Анализируются показатели активности ВМ: загрузка CPU, потребление памяти. Решение о миграции принимается на основании анализа нагрузки ВМ и необходимости соблюдения заданных политик. Анализ исключительно узлов гипервизоров недостаточен, поскольку критическое значение имеет интенсивность изменения памяти ВМ
Какие метрики учитываются при выдаче рекомендаций DRS — или это только преднаписанные в политике правила?
Учитываются метрики загрузки CPU и памяти от встроенного мониторинга платформы. Анализ выполняется на основании правил, заданных в политиках. Расширение набора метрик запланировано.
Можно ли задать правила по CPU и RAM одновременно? Как DRS выбирает целевой узел для миграции? Есть ли аналог SDRS?
Выбор целевого узла осуществляется на основании комплексного анализа метрик. Storage DRS (SDRS) находится в разработке и будет реализован в два этапа: первый этап — балансировка по ёмкости, второй — балансировка по IOPS.
По каким критериям DRS выбирает целевой узел (например, st07-cpu02)?
Выбор целевого узла осуществляется на основании анализа загрузки узлов и рекомендаций DRS. Миграция выполняется на узел с наименьшей текущей загрузкой с учётом активности памяти мигрируемых ВМ.
Если при DRS ВМ не уехала из-за ошибки live-миграции, будет ли попытка отправить следующую, или задание остановится?
Реализована возможность прерывания миграции ВМ (метод /cloudbroker/compute/migrate_abort). В случае неуспешной миграции выполнение задания не останавливается — осуществляется переход к следующей ВМ в соответствии с политикой.
Как решена проблема автоэвакуации ВМ?
Функционал автоматической эвакуации виртуальных машин функционирует в полном объёме. Если Вы испытываете сложности с работой данного функционала на вашей инсталляции, просим обратиться в техническую поддержку, Вам обязательно помогут.
Будет ли механизм автозапуска бесконечно пытаться вернуть узел в строй, или есть алгоритм действий при неудаче?
Проверка состояния узла выполняется с периодичностью 1 раз в 5 минут. При включённом режиме автозапуска, если узел был автоматически переведён в режим обслуживания вследствие потери доступности, после восстановления доступности узел будет автоматически переведён в состояние Enabled. При ручном переводе узла в режим обслуживания автоматическое возвращение в состояние Enabled не производится.
Реализован ли функционал отправки событий на внешние rsyslog-серверы?
Функционал уже реализован и включает два направления отправки: - в BVS (Basis Virtual Security) централизованная агрегация логов для администраторов безопасности; - на произвольные серверы, конфигурируемые в настройках платформы.
Появится ли быстрый переход в аудит/Job при запуске операции — кликабельный таймер в уведомлении?
Обновление веб-интерфейса запланировано. Конкретная реализация механизма перехода по клику из уведомления в соответствующий Job/аудит прорабатывается.
DRS: загрузка хостов или состояние ВМ? Разграничение прав доступа к ВМ. Архитектура виртуальных контроллеров и мультиобраза. Поведение watchdog при изъятии устройства.
Механизм DRS осуществляет мониторинг загруженности виртуальных машин, а не гипервизоров. Сбор метрик выполняется посредством встроенных компонентов мониторинга платформы. Анализируются показатели активности ВМ: utilisation CPU, потребление памяти. Решение о миграции принимается на основании анализа нагрузки ВМ и необходимости соблюдения заданных политик. Анализ исключительно узлов гипервизоров недостаточен, поскольку критическое значение имеет интенсивность изменения памяти ВМ. Разграничение прав реализуется через механизм зон, аккаунтов и ресурсных групп (РГ). Аналогом «папки» могут выступать ресурсные группы, объединяющие ВМ с единой политикой доступа.
Управляющие узлы функционируют как кластер на базе Kubernetes. Репликация состояния — синхронная. Рекомендуется настроить внешнее резервное копирование БД управляющих узлов. Архитектура кластера исключает возникновение ситуации split-brain.
Мультиобраз оперирует исключительно дисковыми образами. Оперативная память не является разделяемым ресурсом в контексте мультиобраза.
Если гостевая ОС корректно обрабатывает hot-unplug, агент watchdog продолжает периодически сбрасывать таймер. Если же извлечение устройства вызывает сбой или зависание гостевой ОС, watchdog сработает по тайм-ауту и выполнит заданное действие (перезагрузку ВМ).