Надо понимать, что важно не только настроить серверы 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), чтобы обеспечить работу с плотным потоком ввода-вывода и выдать хорошую пропускную способность.
RSS
