Для других типов экземпляров VMware Cloud на AWS включено хранилище vSAN, которое базируется на локальных дисках каждого хоста. Хранилища данных vSAN растут вместе с кластером по мере добавления новых узлов. С m7i количество хранилища не зависит от числа хостов, и вы можете настроить его в зависимости от требований к хранилищу.
Ниже рассмотрим производительность виртуальных машин SQL Server, работающих на 3-узловом кластере m7i с хранилищем NFS, по сравнению с 3-узловым кластером i4i с хранилищем vSAN. Инстансы m7i основаны на процессорах Intel, которые на одно поколение новее, чем i4i. Вот чем отличаются эти инстансы:
Методология
Для тестов использовался набор ВМ с 16 vCPU и 24 vCPU. Поскольку экземпляры m7i имели 48 ядер, как 16 vCPU, так и 24 vCPU были равномерно распределены по общему количеству ядер, что облегчало сравнение производительности и делало его понятным. Для поддержки максимального числа ВМ с 16 vCPU на кластере m7i каждой ВМ назначили 60 ГБ ОЗУ.
Для тестов использовали ВМ Windows Server 2022 с установленным Microsoft SQL Server 2022 и применили открытый инструментарий бенчмаркинга DVD Store 3.5 для запуска нагрузок OLTP-приложений на SQL Server и измерения результатов. DVD Store симулирует онлайн-магазин, где клиенты просматривают, оставляют отзывы и оценивают, регистрируются и покупают продукты. Результаты выражаются в заказах в минуту (OPM), что является мерой пропускной способности. Чем выше показатели OPM - тем лучше.
Результаты производительности ВМ SQL Server с 24 vCPU против 16 vCPU
Результаты на рисунках 1 и 2 показывают производительность ВМ с 24 vCPU и 16 vCPU. Линия обозначает общую пропускную способность в OPM по всем ВМ в каждом тесте. Количество ВМ увеличивается в каждом тесте, начиная с 1 и заканчивая максимально возможным, исходя из количества vCPU, соответствующих числу доступных потоков в кластере.
Темп прироста OPM замедляется, когда количество vCPU превышает количество физических ядер и необходимо использовать второй логический поток (hyperthread) на каждом ядре. Это начинается с 8 и 12 ВМ для тестов с 24 и 16 vCPU соответственно.
Столбцы в каждом графике представляют использование CPU трех хостов для каждого теста. По мере добавления ВМ, VMware Distributed Resource Scheduler (DRS) автоматически размещал и, возможно, динамически перемещал ВМ между хостами для управления нагрузкой. Как показывают результаты, это поддерживало использование CPU на всех хостах довольно стабильным, даже когда нагрузка увеличивалась.
Последняя точка данных в тесте с 16 vCPU (рисунок 2) показывает небольшое снижение OPM, поскольку на этом этапе теста кластер немного перегружен. Несмотря на это, можно было продолжить масштабирование производительности кластера m7i, добавляя больше инстансов. В этих тестах был использован только кластер из 3 инстансов, но можно было бы добавить больше инстансов в кластер для увеличения его емкости.
Рисунок 1 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 24 vCPU на ВМ:
Рисунок 2 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 16 vCPU на ВМ:
Рисунок 3 сравнивает производительность ВМ с 16 vCPU и 24 vCPU таким образом, что в каждом тестовом случае назначалось одинаковое общее количество vCPU. Например, для 48 vCPU 2?24 vCPU сравниваются с 3?16 vCPU (по сумме - 48 в обоих случаях).
Рисунок 3 - производительность ВМ SQL Server: 16 vCPU по сравнению с 24 vCPU:
Сравнение производительности m7i с i4i
Те же ВМ были перенесены на кластер i4i и тесты повторили. Важно отметить, что чтобы сохранить ВМ максимально идентичными, им не увеличивали объем RAM, несмотря на то, что в кластере i4i было примерно в 2,5 раза больше RAM.
Как показывает рисунок 4, результаты для i4i были схожи в плане OPM и использования CPU хоста. Основное отличие: получилось запустить до 24 ВМ на i4i против максимума 18 ВМ на m7i. Это связано с большим количеством ядер и большей памятью в экземплярах i4i.
Рисунок 4 - трехузловой кластер i4i VMware Cloud on AWS: SQL Server ВМ и использование CPU хоста на ВМ с 16 vCPU по сравнению с vSAN:
Рисунок 5 показывает различия между m7i и i4i. Поскольку отдельные ядра экземпляров m7i имеют более высокую производительность, чем ядра кластера i4i, рисунок 5 показывает преимущество в производительности на левой стороне графика. Как только экземплярам m7i необходимо полагаться на второй логический поток (hyperthread) от каждого физического ядра для поддержки рабочих нагрузок, производительность i4i становится схожей. И, наконец, когда экземпляры i4i полностью используют преимущество большего количества ядер, их производительность превышает производительность m7i.
Рисунок 5 - различие между m7i и i4i:
Тестирование производительности говорит о хорошей работе SQL Server на m7i в рамках предоставляемой экземплярами m7i ресурсной емкости. Поскольку экземпляры m7i имеют меньше ядер и меньше памяти, чем i4i, важно использовать инструмент VMC Sizer, чтобы убедиться, что платформа соответствует потребностям баз данных.
Также наблюдались немного более высокие задержки с подключенным к m7i хранилищем NFS, но в целом это не оказало большого влияния на результаты тестов. Важно также правильно подобрать хранилище NFS, подключенное к m7i, и установить для хранилища IOPs и пропускную способность на уровни, соответствующие требованиям рабочей нагрузки.
Microsoft SQL Server долгое время считается золотым стандартом для критически важных рабочих нагрузок баз данных среднего класса. Однако полноценное использование возможностей SQL Server требует соответствующей инфраструктуры.
Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.
В VMware vSAN 8 и vSAN ESA произошли значительные изменения, которые включают в себя использование высокопроизводительных NVMe-дисков и новый, быстрый и эффективный путь передачи данных. vSAN ESA обеспечивает эффективность RAID 5/6 с производительностью RAID 1.
Тестирование показало, что 8-узловой кластер vSAN ESA на Lenovo Agile VX Series может обеспечить 720 000 агрегированных IOPS по мере увеличения количества виртуальных машин SQL Server с одной до восьми. Результаты подтверждают последовательную масштабируемость и надежную производительность для рабочих нагрузок.
В документе приведены обширные рекомендации по проектированию и сайзингу, отчеты о проверке решений и лучшие практики для администраторов и владельцев систем на основе Microsoft SQL Server.
Таги: VMware, vSAN, ESA, Storage, Microsoft, SQL, Performance
Недавно компания VMware анонсировала новый тип инстанса для самых тяжелых нагрузок в публичном облаке VMware Cloud on AWS - AWS-i4i.metal. Теперь пользователи могут выбрать один из трех типов инстансов, каждый из которых заточен под определенный профиль задач:
В VMware недавно провели тестирование СУБД Microsoft SQL Server в облаке VMConAWS с помощью инструмента DVD Store, который измеряет производительность баз данных в числе выполненных операций в минуту (orders per minute, OPM).
Для целей тестирования было создано 3 кластера, каждый из трех соответствующих инстансов, которые отрабатывали нагрузки SQL Server:
Для начала была протестирована производительность SQL Server на одной машине каждого из кластеров. Результат получился таким:
Инстанс I4i производительнее I3 на 158% (более, чем в 2.5 раза)
I3en производительнее I3 на 52%
Далее тестовая нагрузка была запущена на двух хостах каждого кластера:
Как мы видим, производительность выросла почти в два раза с примерно одинаковыми потерями для каждого из кластеров. То есть масштабируется эта рабочая нагрузка в облаке VMConAWS хорошо.
Ну и результат при запуске теста на всех трех хостах для каждого из кластеров:
Здесь коэффициент масштабирования по производительности в отношении одного хоста составил 2.6-2.9x, что очень и очень неплохо.
Инстанс I4i показывает себя хорошо как для задач общего назначения, так и для специфических нагрузок, таких как реляционные СУБД (Microsoft SQL Server, Oracle Database, MySQL) и NoSQL базы данных (MongoDB, Couchbase, Aerospike, Redis), а также VDI нагрузки.
Описание тестового окружения представлено на картинке ниже:
На сайте проекта VMware Labs появилось очередное бесплатное средство для администраторов VMware vSphere - SQL30. Эта штука представляет собой ORM-обертку для легковесной БД SQLITE под ESXi.
Python нативно поддерживает взаимодействие с SQLITE за счет модуля "sqlite" (или sqlite3 в python3). Ну а решение SQLAlchemy - это популярная ORM, используемая для взаимодействия с базами данных sqlite из Python. Однако это решение не работает на ESXi, так как многие его пакеты имеют зависимости от других пакетов, которые не могут быть установлены на ESXi.
Решение SQL30 как замена SQLAlchemy - весьма легковесно и написано только с использованием нативных конструкций Python, а также не имеет никаких внешних зависимостей, поэтому работает на ESXi 6.5 и более поздних версиях.
SQL30 вам пригодится для:
Возможности использования разработчиками интерфейсов Python на платформах с ограниченным применением, таких как ESXi
Предоставления разработчикам приложений доступа к базе данных без необходимости знания SQL
На VMware ESXi 6.5 будет использоваться версия Python 3.5, что ниже актуальной версии 3.6, но все равно лучше чем ничего.
Скачать SQL30 можно тут. Инструкции по установки приведены вот здесь.
С момента последних обновлений, инфраструктура отказоустойчивых хранилищ VMware vSAN теперь нативно поддерживает кластеры Microsoft SQL Server. На данный момент эта поддержка реализована только в облачной IaaS-инфраструктуре VMware Cloud on AWS версии 1.6, но скоро она появится и в онпремизной инфраструктуре VMware vSphere.
Суть поддержки заключается в том, что теперь облачный vSAN работает с командами SCSI-3 Persistent Reservation (SCSI3-PR), которые обеспечивают доступ к общим дискам на физическом уровне абстракции.
Таким образом, пользователи SQL Server не нуждаются в перепроектировании их Availability Groups, а могут просто перенести свои кластеры БД в облако.
Чтобы построить SQL Server Cluster нужно расшарить общий диск между его узлам таким образом, чтобы каждый из узлов мог управлять устройством на физическом уровне. Этот подход описан в документе о SCSI-3 Persistent Reservation (SCSI3-PR).
Для включения поддержки SCSI3-PR для выбранного виртуального диска машины нужно:
Выставить режим диска в Independent – Persistent.
Виртуальный диск должен быть привязан к SCSI-контроллеру, для которого параметр SCSI Bus Sharing выставлен в Physical.
Для управления устройством Shared Disk и его Persistent Reservations имеет смысл создать отдельную политику хранилищ в целях лучшей управляемости.
На данный момент для такой инфраструктуры поддерживаются кластеры SQL Server Clusters 2012 и более свежие, работающие на платформе Windows Server 2012 и более свежей. С точки зрения лимитов, поддерживается до 8 узлов SQL Server на кластер и до 64 устройств на узел.
Когда вы используете общий диск, поскольку узлы должны иметь к нему прямой доступ как бы на физическом уровне, вы не сможете использовать такие технологии, как vMotion, снапшоты, клонирование ВМ и прочие.
Вот как создается общий диск с описанными настройками:
Далее такой диск нужно подключить ко всем узлам SQL Server кластера:
Надо понимать, что важно не только настроить серверы SQL, но и саму среду vSAN, в зависимости от характера ваших нагрузок (какие-то базы данных требуют высокой производительности, какие-то большой дисковой емкости и т.п.).
Давайте посмотрим, что это за базовые рекомендации:
1. Общие рекомендации.
Включайте дополнительный хост ESXi к результатам сайзинга по схеме n+1 на случай отказа диска, дисковой группы или всего хоста в целом.
Имейте хороший запас по пропускной способности сети для трафика vSAN, рекомендуется использовать 10G сеть с выделенной полосой для трафика синхронизации. Для All-Flash vSAN это обязательное требование. И не забывайте о резервировании каналов.
Имейте как минимум 2 дисковых группы на хост - это может увеличить полосу пропускания во многих случаях, а также обеспечивает лучшую отказоустойчивость.
Службы vSAN на уровне кластера:
vSAN Performance service (включен по умолчанию в vSAN 6.7) предоставляет метрики производительности в сторонние системы, такие как vRealize Operations, что позволяет эффективно мониторить и решать проблемы.
Вы можете использовать шифрование data at rest (FIPS 140-2 compliant), это не влияет на производительность по IOPS, но дает нагрузку на CPU, поэтому лучше использовать процессоры с поддержкой возможности AES-NI. Для end-to-end шифрования используйте туннели IPSEC. Если нужно зашифровать только отдельную БД, используйте SQL Server native encryption.
vSAN 6.7 поддерживает SCSI-3 persistent reservations для общих дисков при использовании SQL Server FCI. Для этого на уровне кластера надо включить службу vSAN iSCSI Target.
Настройте политики SPBM для данных SQL Server:
Политика Failures to tolerate (FTT): убедитесь, что выставлено как минимум значение 1, не используйте опцию "No data redundancy".
Политика Number of disk stripes per object: используйте значение по умолчанию (1) и подумайте о разделении данных между разными дисками VMDK, привязанными к разным контроллерам vSCSI.
Политика IOPS limit per object: vSAN 6.2 и более поздние версии имеют возможности QoS, которые могут ограничить IOPS, потребляемые дисковым объектам. Не используйте эту политику для задач, требовательных к нагрузкам. Эта фича используется, как правило, для операций резервного копирования и восстановления, чтобы предотвратить забитие полосы пропускания этими задачами.
2. Рекомендации для нагрузок Tier-1 (высоконагруженные OLTP-базы).
Как правило, такие нагрузки по вводу-выводу включают запросы с множественным позиционированием точек записи в базе данных, активность по сбросу грязных страниц кэша на диск, а также запись транзакционного лога. Размер операции ввода-вывода небольшой - в диапазоне 8K - 64K. Можно использовать бенчмарки TPC-E для воспроизведения паттернов OLTP-подобных нагрузок.
Рассмотрите возможность использования All-flash vSAN.
Используйте как минимум диски SAS SSD (а не SATA SSD) - у них больше глубина очереди. Также подумайте о технологии NVMe.
Отключайте дедупликацию и компрессию данных, которые включены в vSAN по умолчанию. Лучше использовать компрессию таблиц на уровне базы данных.
Для object space reservation установите "Thick provisioning" для всех VMDK с данными SQL Server и логами. Это позволит не натолкнуться на проблему нехватки места при использовании тонких дисков. Также в опциях SQL Server лучше установить настройку Perform maintenance tasks, чтобы инициализировать файлы с данными сразу же. Также выделите сразу место под лог БД, чтобы не натолкнуться на недостаток места в гостевой ОС, либо установите настройку его роста в ГБ, а не в процентах.
Не используйте IOPS limit for object.
Используйте RAID-1 mirroring и как минимум FTT=1 для для VMDK-дисков с данными и логом.
Если вы используете дополнительные методы отказоустойчивости, такие как Always On Availability Groups, то вам может потребоваться увеличить FTT. Делайте это не только с точки зрения доступности, но и с точки зрения производительности. Вы можете комбинировать отказоустойчивость Availability Groups на уровне приложения с отказоустойчивостью на уровне дисковой подсистемы.
Если вам требуется доступность SQL между площадками, можно использовать архитектуру растянутых кластеров (vSAN Stretched Cluster).
Подумайте о коммутаторах для трафика vSAN. Оптимально использовать кластеры all-NVMe vSAN, тогда операции ввода вывода будут быстро передаваться между дисковыми устройствами без участия физических контроллеров. Также лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода.
2. Рекомендации для нагрузок Tier-2 (высоконагруженные OLTP-базы).
Это нагрузки от которых не требуется экстремальной производительности, поэтому они должны быть эффективными с точки зрения стоимости. Тут актуальны следующие рекомендации:
Для гибридной среды vSAN (микс HDD+SSD) рекомендуется следующее:
Используйте несколько дисковых групп для увеличения пропускной способности.
Имейте как минимум 10% от емкости данных для пространства кэширования на SSD. Также рекомендуется использовать объем SSD-емкости как минимум в два раза больший, чем рабочий набор данных (working data set).
Используйте, по возможности, устройства SAS SSD вместо SATA SSD.
Если вы используете конфигурацию All-flash vSAN, то:
Используйте дедупликацию и компрессию, если у приложений нет высоких требований по операциям записи.
Если хотите экономить место и не требуется большой производительности, то используйте конфигурацию RAID 5/6 erasure coding, но для транзакционных логов используйте VMDK-диски, размещенные на RAID 1.
Для object space reservation установите "Thick provisioning" для всех VMDK с данными SQL Server и логами.
3. Нагрузки типа Data Warehouse и серверов отчетов (Reporting).
Для таких нагрузок характерен большой размер операции ввода-вывода, так как происходит запрос большого объема данных из БД. Критичной метрикой здесь является не IOPS, а пропускная способность (MB/s). Для генерации таких нагрузок могут быть использованы бенчмарки TPC-H.
Тут приводятся следующие рекомендации:
Для конфигураций All-flash лучше использовать NVMe SSD для хранилищ данных, это даст хорошую производительность по большим операциям чтения.
Для конфигураций All-flash в целях экономии места используйте RAID 5/6 для VMDK с данными БД.
Преаллоцируйте пространство для логов SQL Server, чтобы не натолкнуться на проблему нехватки места.
Не используйте IOPS limit for object, это может ограничить полосу пропускания.
Лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода и выдать хорошую пропускную способность.
В этом техническом документе рассказывается как о средствах обеспечения доступности виртуальных машин с SQL Server со стороны VMware vSphere (технология vMotion, механизмы HA/DRS), так и о технологиях компании Microsoft, которые работают на уровне гостевой ОС (AlwaysOn Availability Groups, экземпляры кластера AlwaysOn Failover Cluster, техника database mirroring, а также функции отсылки бэкапа транзакционного лога - log shipping).
Также в документе описывается применение технологии катастрофоустойчивости VMware Site Recovery Manager совместно с технологиями доступности SQL Server. Кроме того, рассматриваются вопросы резервного копирования и восстановления баз данных, а также накатывание обновлений. Есть и небольшой раздел о лучших практиках.
Компания StarWind Software, производитель лучшего решения для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, выпустила новый документ "High Availability Features in SQL Server 2016 Standard Edition", посвященным возможностям высокой доступности, интегрированным в новую версию СУБД SQL Server 2016 Standard Edition:
Документ будет полезен всем тем, кто планирует обновление с предыдущих версий SQL Server и может быть еще не в курсе, что функции высокой доступности стали обязательным условием построения ИТ-инфраструктуры предприятия.
В блоге VMware появился интересный пост о производительности СУБД Microsoft SQL Server на облачной платформе VMware vCloud Air. Целью исследования было выявить, каким образом увеличение числа процессоров и числа виртуальных машин сказываются на увеличении производительности баз данных, которые во многих случаях являются бизнес-критичными приложениями уровня Tier 1 на предприятии.
В качестве тестовой конфигурации использовались виртуальные машины с числом виртуальных процессоров (vCPU) от 4 до 16, с памятью от 8 до 32 ГБ на одну ВМ, а на хост-серверах запускалось от 1 до 4 виртуальных машин:
На физическом сервере было 2 восьмиядерных процессора (всего 16 CPU), то есть можно было запустить до 16 vCPU в режиме тестирования линейного роста производительности (Hyper-Threading не использовался).
В качестве приложения использовалась база данных MS SQL с типом нагрузки OLTP, а сами машины размещались на хостинге vCloud Air по модели Virtual Private Cloud (более подробно об этом мы писали вот тут). Для создания стрессовой нагрузки использовалась утилита DVD Store 2.1.
Первый эксперимент. Увеличиваем число четырехпроцессорных ВМ на хосте от 1 до 4 и смотрим за увеличением производительности, выраженной в OPM (Orders Per Minute), то есть числе небольших транзакций в минуту:
Как видно, производительность показывает вполне линейный рост с небольшим несущественным замедлением (до 10%).
Второй эксперимент. Увеличиваем число восьмипроцессорных ВМ с одной до двух:
Здесь также линейный рост.
Замеряем производительность 16-процессорной ВМ и сводим все данные воедино:
Проседание производительности ВМ с 16 vCPU обусловлено охватом процессорами ВМ нескольких NUMA-узлов, что дает некоторые потери (да и вообще при увеличении числа vCPU удельная производительность на процессор падает).
Но в целом, как при увеличении числа процессоров ВМ, так и при увеличении числа виртуальных машин на хосте, производительность растет вполне линейно, что говорит о хорошей масштабируемости Microsoft SQL Server в облаке vCloud Air.
Кстати, если хочется почитать заказуху про то, как облака VMware vCloud Air уделывают Microsoft Azure и Amazon AWS, можно пройти по этим ссылкам:
Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.
В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:
Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.
Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.
Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:
Смотрим, что получится и нажимаем Ok:
Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:
Как вы знаете, в обновленной версии платформы виртуализации VMware vSphere 6.0 появились не только новые возможности, но и были сделаны существенные улучшения в плане производительности (например, вот).
В компании VMware провели тест, использовав несколько виртуальных машин с базами данных SQL Server, где была OLTP-модель нагрузки (то есть большой поток небольших транзакций). Для стресс-теста БД использовалась утилита DVD Store 2.1. Архитектура тестовой конфигурации:
Сначала на хосте с 4 процессорами (10 ядер в каждом) запустили 8 виртуальных машин с 8 vCPU на борту у каждой, потом же на хосте 4 процессорами и 15 ядер в каждом запустили 8 ВМ с 16 vCPU. По количеству операций в минуту (Operations per minute, OPM) вторая конфигурация показала почти в два раза лучший результат:
Это не совсем "сравнение яблок с яблоками", но если понимать, что хосты по производительности отличаются не в два раза - то результат показателен.
Интересен также эксперимент с режимом Affinity у процессоров для "большой" виртуальной машины. В первом случае машину с 60 vCPU привязали к двум физическим процессорам хоста (15 ядер на процессор, итого 30 ядер, но использовалось 60 логических CPU - так как в каждом физическом ядре два логических).
Во втором же случае дали машине те же 60 vCPU и все оставили по дефолту (то есть позволили планировщику ESXi шедулить исполнение на всех физических ядрах сервера):
Результат, как мы видим, показателен - физические ядра лучше логических. Используйте дефолтные настройки, предоставьте планировщику ESXi самому решать, как исполнять виртуальные машины.
Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), приглашает на бесплатный вебинар "Microsoft SQL Server deployment price reduced by 3 times with StarWind Virtual SAN". На мероприятии пойдет речь о том, каким образом с помощью продукта Virtual SAN можно сократить затраты на внедрение SQL Server аж в три раза!
Дата и время вебинара: 3 февраля в 19-00 по московскому времени.
Группы доступности SQL AlwaysOn стали отличным решением для тех, кто годами искал средства кластеризации баз данных SQL Server. Теперь хранилища на базе локальных дисков серверов позволяют построить кластер высокой доступности SQL Server с использованием стандартной лицензии и узлов AlwaysOn Failover Cluster.
У такой конфигурации появляются следующие преимущества:
Не нужно лицензии SQL Server Enterprise
Упрощенная настройка
Нет необходимости в дорогостоящем физическом SAN или NAS-хранилище
Теперь можно с помощью обычных серверов и ПО StarWind Virtual SAN построить инфраструктуру кластера SQL Server AlwaysOn с функциями высокой доступности, не приобретая лишнего оборудования и ПО, сэкономив в три раза без потери производительности. Как именно это сделать? Приходите на вебинар StarWind и узнайте!
Таги: StarWind, Storage, SQL, Microsoft, Server, HA, Webinar
Мы уже затрагивали тему новой версии продукта Veeam Backup and Replication v8, предназначенного для резервного копирования и репликации виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Напомним, что в восьмой версии продукта будет поддержка работы с массивами NetApp, а также было анонсировано средство для восстановления объектов каталога - Veeam Explorer for Active Directory.
Традиционно Veeam Availability Suite v8 будет представлять собой набор продуктов Veeam Backup & Replication v8 плюс решение для мониторинга и управления изменениями Veeam ONE.
Перечислим основные новые функции пакета:
Новые средства для восстановления объектов Veeam Explorer for Exchange, SharePoint, SQL (впервые появится в v8), AD (подробнее - тут).
Новый продукт Veeam Explorer for Storage Snapshots (HP и NetApp), позволяющий делать резервные копии из снапшотов хранилищ и быстро восстанавливать ВМ из этих копий.
Поддержка EMC Data Domain Boost - появится возможность интеграции с этим механизмом EMC, что сократит окна резервного копирования за счет ускорения создания синтетических полных бэкапов до 10 раз.
Новая технология End-to-End Encryption - теперь передаваемые данные при резервном копировании шифруются (AES 256), и даже если вы потеряете пароль, то все равно сможете восстановить виртуальные машин их резервных копий.
Улучшения репликации - теперь репликация по WAN работает быстрее, появится возможность репликации из бэкапа (для очень удаленных площадок) и появится возможность переключения на резервную площадку в один клик.
Это еще не все, ожидайте позднее полный список возможностей.
Больше деталей можно узнать в пресс-релизе Veeam. Выход новой версии Veeam Backup & Replication v8 и Veeam Availability Suite v8 ожидается в конце августа-начале сентября этого года. Предполагаемые цены в США - $1 100 за Standard Edition, $1 550 за издание Enterprise и $2 300 за Enterprise Plus Edition.
Напомним, что обо всем этом и многом другом компания Veeam расскажет на первой своей собственной конференции VeeamON, которая продет c 5 по 9 октября в Лас-Вегасе.
P.S. Я все еще жду от вас бесплатный билет, коллеги!)
Компания VMware выпустила 17-страничный документ "Performance of Virtualized SQL Server–Based VMware vCenter Database", где рассматриваются основные аспекты производительности базы данных Microsoft SQL Server для сервера VMware vCenter в виртуальной машине инфраструктуры vSphere.
Результаты:
Большинство требовательных к ресурсам операций базы MS SQL на виртуальном vCenter по производительности сравнимы с физической инсталляцией.
SQL Server–based vCenter, управляющий большим количеством хост-серверов ESX и кластеров, вполне может работать в виртуальной машине.
Базы данных MS SQL в общем случае работают почти без потери производительности в виртуальных машинах на vSphere 4.1.
Как многие знают, виртуализация позволяет экономить не только на аппаратном обеспечении и управлении, но и на лицензиях. Например, под одной лицензией в виртуальных машинах может быть запущено 4 копии Windows Server 2008 R2 Enteprise Edition (от конкретного продукта для виртуализации это не зависит)... Таги: Microsoft, Лицензирование, SQL, Server, VMware, vSphere, Hyper-V, VMachines, Storage
Известный поставщик решений для управления виртуализацией VMware vSphere, компания Veeam Software, объявила о скорой доступности продукта для документирования и управления изменениями Veeam Reporter 4.0. Согласно сообщению компании, Veeam Reporter 4.0 будет доступен уже в этом месяце.
Ранее этот же продукт носил название Veeam Reporter Enterprise 3.5 (о нем мы уже писали), кроме того была также специальная версия для консультантов Veeam Reporter, теперь же оба продукта объединились в один, получив имя последнего.
Возможности и функции Veeam Reporter 4.0:
Продукт основан на технологии Microsoft SQL Server Reporting Services (SSRS), что позволяет упростить администрирование системы. Теперь нет необходимости в пакете Microsoft Office на клиентских машинах.
Веб-интерфейс позволяет получить доступ к отчетам о виртуальной инфраструктуре VMware vSphere 4 с любых клиентских устройств через веб-браузер.
Поддержка нескольких одновременных сессий пользователей.
Поддержка коммерческих изданий Microsoft SQL Server и бесплатного Microsoft SQL Server Express.
Полностью переработанный GUI, в котором теперь можно кастомизировать основной вид (Dashboard).
Интеграция с корпоративными порталами, например, Microsoft SharePoint.
Veeam Reporter 4.0 теперь собирает исторические данные о производительности компонентов vSphere, имеются зачатки функций Chargeback (стоимость инфраструктуры), планирования трендов развития, собирает события vCenter.
Появились функции для планирования мощностей при увеличении нагрузок на виртуальную инфраструктуру (Capacity Planning).
Veeam Reporter 4.0 позволяет документировать и управлять изменениями конфигурации VMware vSphere и серверов ESX, появились новые отчеты (например, по Distributed Virtual Switch).
Информация о том, кто, где, когда и как конкретно изменял настройки компонентов VMware vSphere (старое и новое значение).