В версии VMware Data Services Manager 9.1 поддержка Microsoft SQL Server переведена в статус общей доступности на платформе VCF — продукт полностью поддерживается и готов к промышленным нагрузкам.
В демонстрации, подготовленной Эриком Греем (Eric Gray) из подразделения технического маркетинга VCF, показан полный цикл восстановления базы данных на произвольный момент времени. В стенде уже развёрнут промышленный кластер Always On availability group из трёх узлов, на котором работают базы данных. Задача — восстановить одну из этих баз на конкретный момент времени для отладки, не изменяя и не затрагивая работающий кластер.
Исходное состояние стенда
Работа ведётся в интерфейсе управления DSM под учётной записью администратора DSM. Среда заранее подготовлена: настроена интеграция с Active Directory, сконфигурированы S3-совместимые хранилища для резервных копий баз данных и системных бэкапов, а также уже запущено несколько баз данных.
Основное внимание в демонстрации уделяется SQL Server. В окружении уже работает один экземпляр SQL Server, и его можно рассмотреть подробнее.
Одна из особенностей, отличающих SQL Server от СУБД с открытым исходным кодом в DSM, — намеренно проведённое разделение между базовым экземпляром (instance) и пользовательской базой данных. На скриншоте видно, что базовый экземпляр состоит из трёх узлов и представляет собой кластер Always On availability group. Он интегрирован с Active Directory, работает под управлением SQL Server 2022 с накопительным обновлением и находится в использовании.
На этом экземпляре размещены две пользовательские базы данных, названные в честь деревьев — spruce и pine. В рамках операции демонстрируется восстановление базы pine на момент времени с размещением копии на новом базовом экземпляре, предназначенном для отладки.
Создание нового экземпляра SQL Server
Первым шагом создаётся новый экземпляр SQL Server — так не придётся вмешиваться в существующий трёхузловой HA-кластер. Экземпляру задаётся имя (в демонстрации используются названия штатов), после чего выбирается редакция. Для решаемой задачи достаточно редакции Developer, однако DSM предлагает и другие варианты — на случай, если требуются возможности уровня Enterprise.
Далее можно указать имя и пароль административной учётной записи либо оставить эти поля пустыми: тогда DSM сгенерирует учётные данные автоматически. Второй вариант удобнее — при необходимости их всегда можно посмотреть позже.
Интеграция с Active Directory
Здесь проявляется одно из ключевых преимуществ связки DSM и Microsoft SQL Server — работа с Active Directory. В качестве подготовительного шага интеграция с AD в DSM уже настроена: указаны имя домена и учётные данные. Поэтому при создании нового экземпляра достаточно выбрать опцию присоединения к домену.
Для этого указывается заранее созданная на стороне AD учётная запись с необходимыми правами и включается запись DNS-имён. Задаётся IP-адрес сервера AD, выполняющего роль DNS-сервера, и вводится полное доменное имя (FQDN). DSM самостоятельно создаст прямую и обратную записи для этого FQDN, благодаря чему к экземпляру можно будет обращаться по имени, а не по IP-адресу.
Чтобы продолжить, необходимо принять лицензионное соглашение Microsoft и перейти к выбору топологии развёртывания.
Топология развёртывания и инфраструктурные политики
Рассмотренный ранее экземпляр использовал трёхузловую конфигурацию Always On availability group — кластер для обеспечения высокой доступности и отработки отказов. Для текущего проекта, связанного только с восстановлением ради отладки, высокая доступность не нужна, поэтому создаётся одиночный виртуальный экземпляр SQL Server.
В DSM существует понятие инфраструктурных политик — это ресурсы, на которых выполняются сами базы данных. Доступны два варианта: пространство имён vSphere либо политика, создаваемая в клиенте vSphere, — так называемая DSM managed policy. Она представляет собой набор ресурсов: кластер, пул IP-адресов, набор классов виртуальных машин. Эти ресурсы создаёт администратор vSphere, и они становятся местом размещения базы данных.
Пространство имён vSphere в данном стенде было создано в VCF Automation для другого проекта, поэтому оно не используется — выбор делается в пользу политики DSM. Соответствующая политика хранения подставляется автоматически, остаётся выбрать класс виртуальной машины. Произвольные значения CPU и памяти задать нельзя: выбор ограничен классами, подготовленными администраторами. В данном случае четырёх vCPU и 8 ГБ оперативной памяти более чем достаточно.
Если бы речь шла о промышленной базе данных, с которой будут работать администраторы SQL Server, им наверняка потребовался бы включённый агент SQL Server для планирования регламентных заданий, а также специфические настройки конфигурации SQL Server. Всё это задаётся на данном шаге. Для отладочного проекта достаточно значений по умолчанию.
После итогового просмотра всех параметров запускается создание экземпляра. Процесс занимает несколько минут: в фоновом режиме на инфраструктуре vSphere разворачивается новая виртуальная машина, внутри неё устанавливается Microsoft SQL Server, после чего экземпляр вводится в работу.
Настройка политики сервиса данных
Следующий шаг — получить доступ к новому экземпляру баз данных в DSM. Доступ полностью управляется через концепцию политик сервисов данных (data service policies). В рассматриваемом окружении политика для SQL Server уже существует, поэтому вместо создания новой достаточно отредактировать имеющуюся. Эта политика определяет, кто, что и где может запускать.
Сейчас она настроена на применение ко всем пространствам имён — в тестовой среде это самый простой вариант. Кроме того, политика управляет тем, к каким серверам баз данных имеет доступ пользователь.
До этого момента в списке присутствовал только экземпляр nevada — тот самый трёхузловой HA-кластер. Поскольку в среде появился новый экземпляр arizona, его необходимо отметить, чтобы получить возможность разворачивать на этой инфраструктуре новые пользовательские базы данных.
Новый одноузловой SQL Server будет использоваться временно и, скорее всего, впоследствии удалён, поэтому резервное копирование для него делать необязательно. Политика меняется с режима «требовать резервные копии», который необходим при использовании варианта с HA-кластером, на режим «разрешать резервные копии». В результате базы данных на HA-кластере продолжают резервироваться, а для одиночного экземпляра резервное копирование можно не задействовать.
Типы аутентификации остаются без изменений — разрешены оба: Windows Active Directory и связка «имя пользователя и пароль SQL Server». Второй вариант считается менее безопасным, но зачастую более удобным, поэтому пока допускаются оба. После краткой проверки настроек политика сохраняется и готова к использованию.
Восстановление базы данных на момент времени
Далее выполняется возврат к разделу SQL Server и переход на вкладку баз данных, где видны две работающие пользовательские базы. Из существующей базы данных запускается восстановление на определённый момент времени.
Это востребованная возможность. Например, произошло повреждение данных или кто-то внёс изменения, и требуется вернуться назад, чтобы понять, как база выглядела в определённый момент, — ради отладки. В мастере выбирается вариант Custom Time вместо восстановления на последнюю доступную точку, после чего указываются нужные дата и время.
Копия разворачивается не поверх существующего экземпляра, где работает «живая» база, а на новом экземпляре arizona, созданном ранее. База при этом переименовывается — так её проще запомнить.
Имя пользователя не меняется: используется аутентификация Windows и учётная запись Active Directory с именем DBA. Резервные копии для этой базы отключаются, чтобы не засорять корзину S3, — база всё равно будет удалена через день-два. После итогового просмотра параметров запускается восстановление. В результате в среде появляется третья база данных SQL Server, размещённая на другом сервере SQL Server и готовая к работе.
Подключение через SQL Server Management Studio
Дальнейшая работа переносится на рабочий стол Windows, где выполнен вход под той самой доменной учётной записью DBA. Заранее открыта SQL Server Management Studio, в которой уже указано полное доменное имя только что созданного экземпляра базы данных. Соответствующая запись в DNS присутствует — её автоматически создал DSM.
Остаётся ввести имя новой базы данных, работающей на этом экземпляре. Шифрование и доверие сертификату сервера также настроены. После нажатия кнопки подключения база открывается так же, как любая другая знакомая база SQL Server.
Видно, что это копия на определённый момент времени: в ней уже присутствует таблица cities — набор данных о городах со всего мира, и данные в ней есть. Начиная с этого момента разработчик или администратор баз данных может выполнять запросы и выяснять состояние тех элементов, которые предположительно вызывают проблемы и требуют расследования путём восстановления на момент времени.
Итог
Показанный сценарий представляет собой восстановление базы данных SQL Server на момент времени с размещением на полностью изолированном экземпляре. Промышленный кластер при этом не был затронут.
DSM самостоятельно подготовил целевой экземпляр, присоединил его к Active Directory, автоматически зарегистрировал DNS-запись и восстановил базу данных на точно указанную метку времени. Администратор базы данных подключился с использованием аутентификации Windows — без необходимости управлять паролями. Ручных операций с инфраструктурой и заявок в поддержку не потребовалось.
Именно так выглядит управление жизненным циклом SQL Server на платформе VCF в DSM 9.1: автоматизированно, управляемо и с готовностью к промышленной эксплуатации.
Data Services Manager (DSM) 9.0 теперь доступен, и организации стремятся понять, как использование этого дополнения к VMware Cloud Foundation (VCF) может помочь им в реализации решения DBaaS в локальной среде. В этом посте будут рассмотрены убедительные преимущества DSM, адаптированные для трех различных ролей: администратора, DBA и конечного пользователя/разработчика.
Преимущества DSM для администратора виртуальной инфраструктуры
Контроль размещения и отказоустойчивости
Прежде всего, этот продукт разработан с учетом требований администратора виртуальной инфраструктуры. Цель была помочь ему контролировать «разрастание данных» и сохранять контроль над размещением баз данных и сервисов данных в инфраструктуре vSphere. Это достигается посредством конструкции DSM, называемой политикой инфраструктуры. Она определяет, какие вычислительные ресурсы, хранилище, сети и даже какая папка ВМ используются для размещения конкретной базы данных. Это не только упрощает общее управление и использование инфраструктуры, но также помогает с контролем лицензирования, прогнозированием, биллингом и т. д. Такое размещение и контроль становятся еще более детализированными с VCF 9.0, где DSM может использовать политику инфраструктуры на основе пространства имен vSphere для развертывания баз данных и сервисов данных. Администратор создает пространства имен vSphere в Supervisor. Как администратор vSphere, он устанавливает лимиты на CPU, память и хранилище в пространстве имен vSphere.
Через политику инфраструктуры администратор также может определить отказоустойчивость базы данных. В то время как DBA может выбрать, будет ли база данных автономной (один узел) или кластерной (три узла), политика инфраструктуры определит размещение кластерной базы данных с точки зрения vSphere. По умолчанию DSM разместит три виртуальные машины кластерной базы данных на разных хостах ESX в одном кластере vSphere. Однако администратор также может создать межкластерную политику инфраструктуры, которая, будучи выбранной DBA, разместит разные узлы одного и того же кластера базы данных в разных кластерах vSphere, обеспечивая еще более высокий уровень доступности.
Видимость и аналитика
Хотя DSM имеет собственный интерфейс и API, не хотелось бы, чтобы администратор «переключался» между разными интерфейсами при мониторинге баз данных и сервисов данных, развернутых DSM на vSphere. Поэтому VMware интегрировала в клиент vSphere возможность просмотра сведений о базах данных и сервисах данных. С одного взгляда администратор может увидеть список развернутых баз данных, имя экземпляра базы, тип движка (Postgres, MySQL, MS SQL) в клиенте vSphere, а также статус БД, версию, уровень оповещений, число узлов, отказоустойчивость, политику инфраструктуры, политику хранения и т. д. Администраторы могут перейти к более детализированному просмотру и увидеть соответствующее имя виртуальной машины, сведения о размещении, а также использование CPU, памяти и дисков. Хотя это само по себе полезно для администратора, это также чрезвычайно полезно для обсуждений между администраторами и DBA по всем аспектам инфраструктуры, потребляемой базой данных, когда требуется понять использование ресурсов, производительность, масштабирование и другие характеристики. Пример такого представления приведен ниже.
Интеграция с vSphere и VMware Cloud Foundation
DSM интегрируется с основными инфраструктурными продуктами vSphere. В предыдущем параграфе мы упомянули, что администратор может просматривать сведения о базах данных через клиент vSphere. Однако также имеется интеграция с Aria Automation 8.x для тех клиентов, которые хотят использовать этот уровень интеграции. DSM поставляется с пользовательским ресурсом для Aria Automation, который после установки создает элемент каталога сервисов для поддержки DBaaS. DSM 9.0 также интегрируется с VCF Automation. Администраторы могут создавать политики службы данных и назначать эти политики различным организациям для полноценного multitenant опыта DBaaS.
Аналогично осуществляется интеграция с Aria Operations, куда DSM и соответствующие базы данных могут отправлять свои метрики. За последние несколько лет была проделана работа по этим интеграциям, включая создание ряда стандартных панелей мониторинга для различных баз данных. Также в версии VCF 9.0 значительно улучшили мониторинг баз данных - теперь все метрики отправляются в VCF Operations. Более того, метрики теперь могут отправляться из DSM 9.0 в эндпоинт Prometheus для тех клиентов, которые хотят это использовать.
Наконец, в этой секции выделим еще одну интеграцию — с Aria Operations for Logs. В один шаг DSM может отправлять все журналы как из самого DSM-апплаенса, так и из всех его баз данных в единую целевую точку. Эти журналы могут отправляться на любой SYSLOG-эндпоинт.
Все вышеперечисленные точки интеграции должны быть полезны для администраторов, использующих полный стек VCF.
Поддержка
Поддержка Broadcom охватывает управление жизненным циклом движков данных, управляемых DSM, включая развертывание, обновление ОС и программного обеспечения базы данных, масштабирование и кластеризацию. Поддержка самого движка PostgreSQL или MySQL, включая, но не ограничиваясь исправлением ошибок, проблемами производительности и устранением уязвимостей, осуществляется сообществом upstream, при этом Broadcom оказывает содействие по принципу "best-effort".
Кроме того, VMware работает с сообществом с открытым исходным кодом, чтобы предоставить полноценное исправление downstream для любых ошибок, обнаруженных клиентами. Хотя VMware не может гарантировать, когда конкретное исправление будет доступно в какой-либо из баз данных с открытым исходным кодом, они могут создавать пользовательские сборки с исправлениями, которые еще не доступны в версиях open source. Это распространенная модель поддержки для продуктов с открытым исходным кодом, и многие поставщики DBaaS используют ту же модель. Это должно дать клиентам уверенность при выборе DSM для их DBaaS решения.
Преимущества DSM для DBA
Теперь сосредоточимся на DBA и тех преимуществах, которые DSM приносит этой роли.
Интуитивно понятный интерфейс для управления парком БД
DSM предоставляет DBA единую панель управления, которая позволяет легко управлять всем парком баз данных. Ниже показана страница по умолчанию для администраторов DSM с различными параметрами управления и конфигурации.
Управление жизненным циклом
Команда DSM регулярно предоставляет обновления для DSM. Это включает обновления для виртуального модуля DSM, гостевой ОС, используемой узлами базы данных, версий Kubernetes в этих узлах, а также собственно самих баз данных. Единственное, что требуется от DBA — загрузить и подготовить обновление. Как для виртуального модуля, так и для баз данных доступны окна обслуживания. Если обновление подготовлено, и наступает окно (обычно в ночь с субботы на воскресенье), обновление применяется автоматически. Никому не нужно вручную управлять жизненным циклом ОС виртуальных машин или кластера K8s — DSM делает это автоматически. Этот аспект часто упускается при сравнении DSM с другими решениями DBaaS.
Еще один важный момент — DSM теперь умеет обновлять как основные (major), так и минорные версии базы данных. Хотя при мажорный обновлениях DBA должен проявлять осторожность (например, проверить совместимость расширений), наличие такой возможности является значительным преимуществом.
Автоматизированные резервные копии и восстановление к точке во времени
Как и управление жизненным циклом, резервное копирование может быть автоматически настроено на этапе развертывания базы данных. Если эта опция включена, DSM начнет выполнять резервные копии сразу после включения базы данных. По умолчанию для Postgres раз в неделю выполняется полный бэкап. Ежедневные бэкапы выполняются каждый день, а журналы WAL отправляются каждые 5 минут или по достижении 16 МБ — что произойдет раньше. Для MySQL и MS SQL Server существуют собственные расписания по умолчанию. Благодаря такому автоматизированному расписанию резервного копирования доступны восстановления к точке во времени для всех баз данных.
Масштабирование — In / Out / Up / Down
DSM позволяет DBA легко масштабировать топологии баз данных — от автономного узла до трехузлового кластера и обратно. Также допускается вертикальное масштабирование, путем смены класса виртуальной машины, что увеличивает доступные CPU и память. И наоборот — если ресурсы остаются неиспользованными, DBA может уменьшить класс ВМ и сократить потребление ресурсов. Это особенно полезно, например, для закрытия месяца, квартала или во время “Black Friday”, когда базе данных временно требуются дополнительные ресурсы. После окончания «пика» ресурсы можно освободить.
Клонирование
DSM позволяет DBA создавать клоны базы данных, если возникает такая необходимость. Это полезно для тестовых и девелоперских сред, когда разработчики хотят запускать запросы на «живых» данных, не затрагивая продуктивную базу.
Интеграция с LDAPS
DSM поддерживает защищенный LDAP как для доступа к самому DSM, так и к базам данных. Это делает назначение прав доступа более безопасным и удобным. При развертывании базы данных DBA может выбрать интеграцию с Directory Service и затем с помощью простого оператора GRANT предоставить LDAP-пользователям доступ к базе. Кроме того, DSM поддерживает защищенный LDAP и для собственного UI, что позволяет пользователям и разработчикам (при наличии прав) самостоятельно создавать базы данных через DSM-интерфейс. Поддерживаются как ticket-based, так и self-service подходы.
Управление сертификатами
Для обеспечения защищенного доступа к базе данных необходимы сертификаты. DSM предоставляет два варианта — использовать собственные самоподписанные сертификаты DSM или загрузить пользовательские сертификаты. DBA может применить сертификаты как при создании базы, так и после ее развертывания. UI и API DSM делают процесс добавления сертификатов очень простым. С учетом современных требований безопасности — это крайне важная функция.
Аудит и оповещения
DSM предоставляет различные механизмы для оповещений, а также встроенные функции в UI. Оповещения могут отправляться по электронной почте (SMTP), а также через webhook-механизм в сторонние системы, такие как ServiceNow или Slack. Таким образом, DBA-команда никогда не пропустит важное событие.
Для целей соответствия требованиям, DSM ведет аудит событий, который DBA может быстро просмотреть. В версии DSM 9.0 журналы аудита также передаются на настроенную систему получения логов.
Высокая отказоустойчивость
Хотя это может показаться зоной ответственности администратора, именно DBA выбирает нужный уровень отказоустойчивости при создании базы. Эти параметры управляются через инфраструктурные и storage-политики. Как упоминалось ранее, кластерные базы могут быть размещены либо в одном кластере vSphere, либо распределены по разным кластерам. DBA выбирает нужный вариант, выбирая соответствующую политику.
Шифрование
Для шифрования можно использовать функцию VM Crypt, что позволяет шифровать отдельные базы данных. Это определяется в политике хранения, входящей в инфраструктурную политику. Альтернативно можно шифровать весь datastore (например, vSAN), и тогда любая база, размещенная на нем, будет автоматически зашифрована. Оба подхода поддерживаются DSM.
Отказоустойчивость и репликация
DBA может использовать репликацию для удаленной защиты базы. При наличии нескольких сред vSphere вторичный узел Postgres может быть размещен в другой среде vSphere с другим экземпляром DSM. В UI доступны элементы управления для повышения вторичного узла в первичный и наоборот. В случае потери целой среды vSphere можно выполнить восстановление баз данных в другую среду и продолжить работу.
Host-based access при развертывании
Файл pg_hba.conf в Postgres определяет, какие пользователи из каких сетей могут обращаться к базе. Через UI DSM DBA может заранее задать правила доступа при развертывании, не заходя в базу после ее создания. Это предотвращает ситуацию, когда база находится в «незащищенном» состоянии, пока эти правила не будут вручную настроены.
Расширенные параметры при развертывании
Аналогично предыдущему пункту, DBA может задать расширенные параметры при создании базы, не выполняя это как отдельный пост-шаг. Это сокращает время развертывания.
Защита от удаления
Пользователи DSM могут восстановить базу данных после ее удаления. Период хранения удаленной базы составляет 30 дней, но может быть уменьшен или увеличен при необходимости.
Преимущества DSM для конечного пользователя/разработчика
Одной из основных задач DSM является обеспечение модели самообслуживания DBaaS. Поэтому DSM предоставляет конечным пользователям и разработчикам простой механизм для запроса и доступа к базам данных. Рассмотрим эти возможности далее.
Интуитивно понятный интерфейс
Пользователи DSM получают очень простой интерфейс, позволяющий легко создавать, обновлять и удалять базы данных по мере необходимости. Они не видят настроек конфигурации и не видят базы данных других пользователей. Для тех конечных пользователей, которые предпочитают UI для развертывания баз, это интуитивно понятный и простой процесс.
Kubernetes и REST API
VMware понимает, что многие разработчики предпочитают не использовать пользовательский интерфейс. В некоторых случаях развертывание базы данных является частью более крупного CI/CD-пайплайна для тестирования. В связи с этим DSM предоставляет как API для Kubernetes, так и REST API. Это позволяет автоматизировать развертывание баз данных через DSM. API доступны на официальном сайте DSM API.
Развертывание баз DSM из удалённых K8s-кластеров
Многие разработчики уже используют Kubernetes для разработки приложений. Эти кластеры могут быть ограничены по ресурсам, например, использовать только локальное хранилище. Кроме того, SRE-команды сталкиваются с проблемой того, что разработчики создают «неконтролируемые» базы данных и сервисы данных, что приводит к конфликтам по ресурсам и вопросам соответствия. Благодаря Consumption Operator в DSM разработчики могут создавать собственные базы данных DSM на инфраструктуре vSphere и подключаться к ним из своих Kubernetes-кластеров.
Итог
Data Services Manager приносит много полезных функций в VCF. DSM предоставляет DBaaS-решение для VCF с той же поддержкой, что и сам VCF. DSM уже работает в производственной среде и в масштабах, управляемых Broadcom IT на протяжении последнего года (вся разработка Broadcom использует DBaaS через DSM на VCF). У Broadcom также есть множество крупных клиентов, реализующих аналогичные сценарии. Надеемся, этот обзор преимуществ DSM был для вас полезен, и вы рассмотрите возможность использования его в своей среде VCF.
Недавно вышла версия VMware Data Services Manager (DSM) v2.1.1 (о версии 2.1 мы рассказывали вот тут). В связи с этим релизом Кормак Хоган решил создать несколько коротких видеороликов, чтобы подчеркнуть некоторые улучшения, которые были внесены в продукт. Напомним, что VMware Data Services Manager (DSM) дает разработчикам средства самообслуживания, которые позволяют регулировать потребление ресурсов, обеспечить комплаенс и соответствие политикам резервного копирования компании, а также дает другие полезные инструменты.
В видео ниже демонстрируется, как начать работу с DSM v2.1.1. В нем показано, как загрузить продукт с портала поддержки, а также рассказывается об использовании плагинов клиента vSphere для развертывания DSM в вашей онпремизной инфраструктуре vSphere.
В ролике показано, как создать свою первую инфраструктурную политику для защиты ресурсов vSphere при развертывании баз данных и сервисов данных. Видео также рассказывает, как завершить настройку DSM, войдя в интерфейс и добавив объектное хранилище для резервного копирования и журналов виртуального модуля (Virtual appliance) провайдера, а также для резервных копий вашей базы данных. После завершения настроек вы будете готовы к включению и развертыванию БД.
Напомним, что VMware Data Services Manager (DSM) дает разработчикам средства самообслуживания, которые позволяют регулировать потребление ресурсов, обеспечить комплаенс и соответствие политикам резервного копирования компании, а также дает другие полезные инструменты.
Давайте посмотрим на новые возможности DSM 2.1:
Упрощённая установка
Пользователи VMware Cloud Foundation автоматически получают право на использование DSM. В новой версии упрощено развертывание, так как теперь базы данных включены в саму DSM-установку. Это исключает необходимость ручной загрузки и загрузки образов баз данных в S3-совместимое хранилище. Теперь при установке клиентского плагина DSM 2.1 и устройства все сервисы данных могут быть быстро активированы.
Улучшенная видимость для администратора
DSM 2.1 предоставляет администраторам больше информации о потреблении ресурсов vSphere базами данных. В клиенте vSphere теперь отображаются дополнительные данные, включая распределение ролей баз данных по виртуальным машинам и метрики ресурсов. Это помогает администраторам управлять потреблением ресурсов и устранять неполадки.
Кластеризация MySQL
В версии DSM 2.1 была реализована поддержка кластеризации MySQL, что обеспечивает создание трёхузловых баз данных с одной основной и двумя репликами. Поддержка PostgreSQL также продолжает предлагать как одиночные, так и кластерные топологии.
Управление сертификатами
DSM 2.1 предлагает улучшенные средства управления сертификатами для безопасного общения как внутри компонентов DSM, так и с внешними системами. Поддерживается добавление корневых сертификатов, что обеспечивает безопасное подключение к системам vCenter, S3-хранилищам и другим. Также поддерживается использование собственных сертификатов клиентов.
Поддержка LDAPS для доступа к базам данных
Теперь DSM поддерживает безопасный доступ к базам данных через LDAPS для OpenLDAP и Active Directory. Это расширяет возможности управления доступом пользователей к базам данных, что было востребовано многими клиентами.
LDAPS можно включить для базы данных уже после ее развертывания:
Улучшенная интеграция с Aria Operations for Logs
DSM 2.1 добавляет поддержку протокола cfAPI для интеграции с Aria Operations for Logs, что упрощает фильтрацию журналов и создание панелей мониторинга. Все компоненты DSM теперь имеют собственные теги для удобства анализа логов.
Интеграция с интерфейсом Cloud Consumption (CCI)
Новая версия DSM интегрируется с интерфейсом Cloud Consumption, что позволяет пользователям управлять PostgreSQL базами данных через Aria Automation/CCI. Запросы обрабатываются через Supervisor Services.
Интеграция с vCloud Director
Для провайдеров облачных услуг DSM 2.1 теперь есть интеграция с VMware Cloud Director через расширение Data Solutions 1.5. Это упрощает процесс предоставления баз данных DSM через интерфейс самообслуживания.
RSS
