Я планирую заменить оборудование на майский SQL Server и обновить его до SQL Server 2016 Enterprise. AlwaysOn AG будет построен на базе двух узлов + dr.
Я имею в виду два варианта хранения:
имеют только локальные диски, ssd в RAID1, с отдельными дисками для Windows, Data, Logs и TempDb имеют гибрид локального хранилища с ssd для TempDb (RAID1), а остальные диски для Windows, Data и Logs должны быть предоставлены из SAN по сети Я лично предпочитаю вариант, когда все находится в локальном хранилище, потому что:
вы избавляетесь от единой точки отказа (SAN), увеличивая скорость в локальном хранилище, в SAN не будет ssd, нет узких мест в сети Есть ли какие-либо серьезные недостатки в использовании локального хранилища?
Является ли использование SAN для хранения лучшим вариантом?
Независимо от решения, оборудование будет арендовано у поставщика оборудования. Так что покупок не будет.
Заранее спасибо!
Что касается Microsoft документы вам следует выбрать либо локальное хранилище, либо общее хранилище, либо Microsoft Storage Spaces Direct.
Предполагая, что вы достигли доступности для MSSQL Server, я бы посоветовал вам использовать локальное хранилище, идентичную настройку для каждого хоста, которая обеспечит вам одинаковую производительность в случае отказа узла.
Используйте общее хранилище, если вы предпочитаете MSSQL FCI.
Что касается SAN, то его SPoF. по моему мнению
Как всегда, у всего есть много достоинств и недостатков.
Массив хранения обеспечивает высокую емкость и централизованное управление. Вы можете сделать снимок некоторых томов и передать их другому хосту. Хотя переключатели и кабели для подключения SAN могут быть немного сложнее.
В локальном хранилище задействовано меньше серверных узлов, и оно может быть более знакомо администратору ОС. Могут быть ограничения на емкость, которая уместится на сервере, если вы не добавите что-то вроде дискового корпуса.
Репликация на уровне базы данных позволяет относительно легко использовать две независимые системы хранения для решения непрерывности бизнеса. Затем отказ уровня хранения можно уменьшить, активировав аварийное восстановление. Анализ единой точки отказа по-прежнему является хорошей идеей, проверяя наличие резервных источников питания, путей SAN и т. Д. Копия аварийного восстановления, возможно, на удаленном сайте, ускоряет восстановление, если первичная копия становится недоступной.
Лично я вижу, что сети хранения данных становятся пережитком ушедшей эпохи. Не поймите меня неправильно - они, как и мэйнфреймы, имеют свое место, и при правильном использовании они очень ценны. Без них были бы невозможны крупные установки виртуализации. Когда-то общее хранилище, такое как SAN, было единственным способом сделать такие вещи, как SQL Server или VMWare ESXi, высокодоступными.
Но получить SAN, работающую так же быстро, как локальное хранилище SSD, очень дорого. Чтобы получить такой же быстрый, как хранилище NVMe (например, Intel P3608), нужно шестизначное число. По сравнению с 8000 долларов за топовый P3608 с 4 ТиБ - дешевле, если вам не нужно 4 ТиБ хранилища.
Благодаря AlwaysOn SQL Server, обеспечивающему хороший вариант высокой доступности, с локальным хранилищем, синхронными или асинхронными вариантами репликации и с Распределенные группы доступности, нет причин развертывать SAN для подавляющего большинства новых установок SQL Server.
Что касается SQL Server, то здесь нет недостатков в использовании локального хранилища.