Введение
Уже давно, начиная с MS SQL 2012 в качестве альтернативы класическому Windows Server Failover Cluster для MS SQL существует альтернатива в виде AlwaysOn groups баз данных, но так ли хороша эта альтернатива и когда именно её следует применять?
Тезисы
Группы доступности баз данных по большому счету является хорошо автоматизированным и доработаным с точки зрения использования и сопровождения(в первую очередь имею ввиду автоматический failover) механизмом зеркалирования (mirroring) работающим, по определению, на уровне баз данных и транзакций к ним. Классический Failover Cluster находится в стеке ниже - уровень самого приложения MS SQL.
Отсюда следует и потенциальный негативный момент: AlwaysOn обеспечивает доступность на уровне баз данных и объектов хранящихся в ней (учетные записи итд...), тогда как FailoverCluster покрывает всю СУБД включая maintenance операции, agent jobs etc... Соответственно, для полноценного отказоустойчивого экземпляра СУБД AlwaysOn требует дополнительных ручных действий, в случае наличия такой необходимости.
Второй момент касается консистентности данных, хотя скорее лучше подобрать тут другое слово, но Вы, поймётё о чем речь.
При AlwaysOn копии баз данных находятся на всех узлах. Стоит отметить, что в зависимости от режима фиксации транзакций (синхронный, асинхронный) в определенных случаях может возникнуть проблема с консистентностью (потеря транзации в момент краха основной копии). При Failover Cluster копия данных одна единственная, с возможной репликацией на блочном уровне между системами хранения/датацентрами.
Из озвученной выше особенности по количеству копий вытекает как следствие соответствующая особенность: AlwaysOn позволяет работать с копией в ReadOnly, в частности для работы с отчетами (Repoting).
Так же из особенности по механизмам хранения есть и ешё одно следствие: при FailoverCluster между узлами должен быть shared storage, что, конечно, можно реализовать средствами встроенными в операционую систему Windows Server 2016 , но сам факт наличия, дополнительного элемента в зависимостях отказоустойчивого решения не всегда может быть уместен. К тому же, никуда от withness шары в FailoverCluster не деться. При AlwaysOn Потребуется withness шара (по best practice это сторонний HA сайт/DC/ шара в Azure), но shared storege не нужен, по определению механизма AlwaysOn, котороый хранит копии на узлах.
В случае простой отказоустойчивой конфигурации из двух узлов, AlwaysOn может быть нецелесообразным по стоимости, так как требуется MS SQL Enterprise Edition, в отличии от Failover Cluster, где существенно более бюджетных MS SQL Standard лицензий будет достаточно.
Эпилог
Как завершение заметки, следует отметить, что новые технологие, поставляемый маркетологами порой как панацеая, как правило всегда не заменяют существующие, а являются альтернативой, порой уместно применимой в определенных ситуациях и сценариях.
