Вчера у нас произошел сбой рейда на сервере, на котором размещались базы данных и IIS.
Мы пытаемся определить наилучший способ продвижения вперед с точки зрения нашей среды хостинга IIS и MSSQL.
Нам нужна избыточность на стороне IIS и стороне SQL.
В некоторых наших приложениях мы используем pfSense для балансировки нагрузки двух веб-серверов (липкие сеансы работают плохо, поэтому мы перешли в состояние сеанса в базе данных). Эти два веб-сервера работают с одним экземпляром MSSQL, на котором запущен SQL Express (бесплатно, наши базы данных очень маленькие, самый большой - 1 ГБ).
Я достаточно уверен в нашей балансировке нагрузки IIS, поскольку, когда мы запускаем исправления, это «просто работает», и мне действительно не нужно много делать.
Однако наша инфраструктура SQL Server меня беспокоит.
Как лучше всего создать отказоустойчивый стек sql?
Изменить: теперь, когда я думаю об этом, кластер не обязательно решил нашу проблему. У нас вышло из строя два диска в RAID5. Один 100% отказал, другой еще не умер, но помечен как сбой с поврежденными секторами. У нас была одна база данных, которая находилась в плохих кластерах, которую нам пришлось восстанавливать из резервной копии. Кластер либо сломался, либо поместил бы неверные данные по всему кластеру. Ах!
Несмотря на то, что вопрос не в этом, я хочу отметить, что использование состояния сеанса в базе данных снижает производительность. Есть некоторые неприятные проблемы (с некоторыми обходными путями) известно, что это происходит с этой моделью хранения сеанса. Стоит потратить время на то, чтобы закрепленные сеансы работали правильно, чтобы вы могли использовать хранилище InProc - даже если это означает некоторую асимметричную нагрузку на веб-интерфейсы.
Я собирался углубиться в репликацию слиянием, секционирование, репликацию одноранговых транзакций и другие методы масштабирования / FT / HA с SQL Server, но они кажутся излишними для вашей среды - и требуют не-Express SQL Server. Отказоустойчивая кластеризация SQL Server с MS Cluster Services, хотя и ограниченная, предназначена для обеспечения отказоустойчивости. Однако обычная односайтовая конфигурация полагается на общее хранилище, которое вам совсем не помогает.
Я собираюсь порекомендовать вам сосредоточиться на более качественном хранилище, используя SAN (или даже NAS, в зависимости от вашей нагрузки и бюджета) с RAID 10 (или 6, если вы не можете себе это позволить) с горячим резервом, частое резервное копирование, и желательно на устройстве, которое активно сканирует на предмет проблем с целостностью, а не просто на дешевом комплекте дисков. (Хотя можно было бы и хуже, чем OpenFiler на приличном железе.)
Если вы ограничены RAID 5 на жестких дисках на серверах (без общего хранилища), изучите «многосайтовый» отказоустойчивый кластер с помощью репликация, хотя вы можете найти цену на внедрение (SQL Server Enterprise Edition - минимальное требование) очень непомерно высокой.