Сказка про MS SQL и высокую доступность

         Подумал я грешным делом а не научится ли мне жить на два датацентра, как это делают взрослые компании. Думаю - MS SQL это же классный сервер, столько бабла за него отдаем. Entrerprise редакция обязана уметь master-master репликацию. Начал читать и тут постигло меня разочарование страшное. Выяснилось что умеет MS SQL в области высокой доступности приблизительно ничего. Ну то есть на уровне MySQL. Это был спойлер, а теперь расскажу по порядку. 

           Первое что предлагает Microsoft - это высокая доступность по высоким ценам, типичное enterprise решение - покупаешь SAN(СХД или хранилка по нашему), подключаешь ее к двум серверам. На этот шаренный диск ставишь MS SQL Server и получаешь решение которое называется Windows Failover Cluster или SQL Server Failover Cluster Instances (FCIs). По сути база и лог транзакций хранится на шаренном диске, только один SQL Server может принимать/обрабатывать транзакции, второй стоит рядом. Эта архитектура не гарантирует ни высокую доступность ни распределенность. Единственное для чего он годится - это установка обновлений. Ставишь обновления на пассивную ноду, переключаешься - смотришь, если все ок - ставишь обновления на вторую ноду.

           Следующее что нам предлагает Microsoft - это Availability Groups(AG). У этой штуки есть еще коммерческое название - Always On Availability Groups. Microsoft не была бы Microsoft если бы не придумала для банальной репликации "продающее" название.  Да, к сожалению вы  не ослышались - весь этот хваленый Always On это банальная master->slave репликация с кучей ограничений.  Дело в том что Always On требует наличия Windows Server Failover Clustering(WSFC),  который в свою очередь опирается на Active Directory и требует чтобы все сервера входящие в WSFC находились в одном домене. Отсюда вытекает интересное следствие -  Availability Group также должна находится в одном домене, соответсвенно использовать Availability Group для репликации между серверами находящимися в разных датацентрах становится практически невозможно (только если вы не хотите растянуть один домен на два датацентра, а вы скорее всего не хотите этого делать). Еще Availability Group не поддерживает больше 8 реплик (даже в Enterprise редакции). Ну и естественно Availability Group не поддерживает master-master репликацию. 

             Так что же умеет Availability Group ? Умеет перенаправлять read-only траффик на реплику. Причем для того чтобы это работало само приложение должно указать при подключении флаг - ApplicationIntent=ReadOnly. То есть коннекты должны быть разделены на read only и read-write на уровне приложения, а это значит что неподготовленное приложение вы не сможете просто так отмасштабировать на чтение. Потребуется рефакторинг. Отдельно стоит рассказать как происходит разделение траффика на read/write. Если вы подключаетесь к Availability Group Listener то вы подключитесь к primary replica (SQL Server master) и SQL Server отвечает за то чтобы знать топологию AG и если в нем имеется нода в состоянии synchronized настроенная для приема read-only запросов, то SQL Server отправляет клиенту параметры для прямого подключения к read-only серверу. Такой редирект на уровне MS SQL протокола поддерживают далеко не все клиенты. 

        Еще AG умеет реплицироваться синхронно и асинхронно. Умеет auto failover, но только если: 

• Используется синхронный режим репликации
• Реплика на которую мы планируем failover находится в состоянии synchronized
• Windows Server Failover Clustering(WSFC) имеет кворум.
• Autofailover настроен должным образом

В общем у меня не получилось придумать сценария при котором автоматическое переключение могло сработать как надо. WSFC по сути отвечает за синхронизацию на уровне серверов, и если на уровне серверов связи нет(нет кворума) - то автопереключение работать не будет. То есть при физическом отказе сервера сказки не случится. А зачем тогда весь этот цирк с конями если он работает только во время плановых учений ?

          При использовании асинхронного режима оно умеет только в ручную переключать master на одну из реплик с частичной потерей данных, причем про частичную потерю данных говорится при каждом упоминании.  Чтобы все сразу воодушевились - как здорово просрать данные. Давай немедленно использовать асинхронную репликацию. Причем как при ее использовании данные не просрать не сказано. К примеру тот же MySQL лет 10 как умееет failover без потери данных при асинхронной репликации.

           Отдельно стоит рассказать о взаимоотношениях между WSFC и AG. Как я уже сказал AG опирается в своей работе на WSFC. WSFC в свою очередь отвечает за мониторинг состояния SQL Server запущенного на локальной машине и за поддержание связности с другими серверами входящими в WSFC кластер. Мониторинг состояния SQL сервера сделан в стиле Microsoft - через shared memory. Есть процесс RHS.exe который шарит память с SQL Server, они там по очереди timestamp обновляют. Не обновил timestamp - значит умер. Идея здравая, но зачем это через shared memory делать ?? 

          Следующий интересный момент - как происходит failover. Для подключения к Availability Group используется так называемый Availability Group Listener. Listener состоит из Network Name Resource про который я уже писал и порта. Когда происходит failover все коннекты обрубаются, и клиенты начинают переподключаться. Сколько-то retry делается внутри  SQL клиента, но также рекомендуется выполнять переподключения в приложении. И в общем после какого-то количества повторов клиенты подключаются к новому серверу.

          На этом казалось бы уже длинная сказка про отсутсвие вменяемого HA setup-а должна подойти к концу. Но надо рассказать про еще одного героя - Distributed Availability Group. DAG появился как костыль, позволяющий строить cross-site setup (инсталяции работающие более чем в одном датацентре).  DAG позволяет объединить 2 или более AG в единую Availability Group. По сути позволяет реплицировать лог транзакций из primary replica одной AG в primary replica другой AG, а та уже в свою очередь реплицирует его на свои slave-ы. То есть DAG позволяет построить многоранговую сеть репликации и обойти ограничение на 8 slave-ов. Автоматически реплицироваться она не умеет, все это придется делать руками. 

       В общем как-то так. Никакой master-master репликации там близко нет.

MS SQL сервер

    В прошлом посте я много всего написал про Microsoft, и в основном все не очень хорошее. Но на самом деле это не так. Он просто другой, он просто очень сильно отличается от open source RDBMS с которыми я раньше имел дело. Если образно сравнивать MS SQL с MySQL, то MySQL это как советская армейская машина - типа УАЗ. Относительно простая, все настройки хорошо документированы - но чтобы из изменить нужно лезть в конфиг. В принципе если его прокачать и правильно использовать - то он умеет все то же что умеет MS SQL, но все это разбросано по разным местам и требует тщательной подгонки друг к другу. MS SQL - это как иномарка среднего класса, с автоматической коробкой передач. У тебя есть некоторое количество настроек, аккуратно выведенных на переднюю панель. Ты даже можешь управлять работой MS SQL, но на очень простом уровне. Что-то типа  - переключить коробку в режим "спорт" (OLTP ) или езда по бездорожью с прицепом (OLAP). Правда на самом деле под капотом есть куча  скрытых настроек(а-ля блок управления двигателем), совершенно не документированных, но которые вы можете менять через редактирования ini файлов, но уже на свой страх  и риск. В обем самое то - для комфортной езды сертифицированных админов.

        На последок пару полезных ссылок про MS-SQL Server:

1. http://technet.microsoft.com/en-us/library/hh231298.aspx - детальная информация по конфигурирования MS SQL сервера. Ввиду общей убогости документации Microsoft, найти этот источник удалось далеко не сразу.

2.  http://technet.microsoft.com/en-us/library/hh230806.aspx - информация по настройке Analysis Services. Для тех кто не в курсе - Analysis Services - это как бы реинкорнация MS SQL в теле OLAP

3. Hardware Sizing a Tabular Solution (SQL Server Analysis Services) - о том как рассчитывать требуемый размер RAM для нормальной работы Tabular Models.

4.  Performance Tuning of Tabular Models in SQL Server 2012 Analysis Services

5.  http://technet.microsoft.com/en-us/library/cc280449.aspx - про сжатие данных в MS SQL

6. Data Compression: Strategy, Capacity Planning and Best Practices

7. Про PDW или Parallel Data Warehouse

8. Microsoft White Papers for SQL Server 2012

Про данные, много данных. Или просто DWH

         Раньше мне как-то не приходилось сталкиваться в плотную с Data warehouse. Все с OLTP базами работал,  и прямо скажем OLAP не вызывал  у меня особого интереса.  Но не так давно на голову мне свалился DWH, один из двух наших DWH.  Тот что сделан на соплях. Так что пришлось с разбега окунуться во все это.  

          В общем новый анекдот от Microsoft: in-memory data warehouse. Они похоже реально верят что оперативка является бесконечным ресурсом. И очень дешевым. В MS SQL Server 2012 они всячески продвигают свое новое решение - tabular modeling. Если в кратце - это новый тип моделей, которые работают на  xVelocity(VertiPaq) analytics engine. Они называют его предметом искуства (дословно: state of art), изредка при этом упоминая что это IN MEMORY SOLUTION.  Справшивается - зачем строить решения для бизнес аналитики на in-memory движке ?  У вас в DWH полтора гига данных ?? или может быть целых два ??? По моему DWH это минимум пол терабайта данных. Если у вас их меньше - держите их в OLTP базе и не трахайте мозг себе и другим. Вам больше не нужен DWH. 

          Но когда построением DWH занимаются "менеджеры" они легко ведутся на этот маркетинг.  И компания оказывается в заложниках MS решений, и вынуждена покупать сервера с сотнями гигабайт оперативной памяти, просто для того чтобы все днные туда поместились. Иначе все - перестанет работать игрушка для MD.  Но кто-нибуть подумал что данные в DWH добавляются быстрее чем 64 килобайта в год, как об этом думают в Microsoft.

                Но даже если вы выберете другой тип моделей - multidimensional models или tabular models in DirectQuery mode - не все так хорошо как вы думаете.  Вы все равно остаетесь в заложниках одного сервера.  MS SQL это  SMP решение, и без танцев с бубнами вы не сможете распределить данные по нескольким серверам. Это значит что масштабироваться вы все равно сможете только вертикально - покупать все более и более дорогие сервера. Скажем до 10TB вы сможете держать на одном MS SQL instance, но потом ценник на сервера улетит в небеса. Вообще у Microsoft есть ответ и в этом случай - PWD, Parallel Data Warehouse. Но это уже совсем другие деньги, так сказать.  Хотя они и считают его бюджетным - по сравнению с Oracle Exadata, Teradata - оно конечно выглядит бюджетным, но вообще ценник кусается. 

             А выше идут специализированные аапаратно-программные решения от Oracle, IBM и узко специализированных вендоров. В решениях такого класса самые ресурсоемкие операции - типа сжатия/распаковки данных и маршрутизации данных между нодами реализованы в железе, на FPGA.  Естественно никакая софтовая реализация по скорости с FPGA тягаться не может.

           Но самое парадоксальное что я выяснил - есть open source решения которые могут  успешно конкурировать с решениями от Microsoft/Oracle/Teradata практически во всех сегментах, кроме последнего. Это Hadoop. Бесплатное, работает на дешевых серверах - бери и ездий. Для статистического анализа можно использовать язык R, который стал де-факто стандартом для статистов.  Единственное - runtime для R, который поддерживает параллельную обработку данных в Hadoop является проприетарным. Но я думаю там ценник совсем другого уровня, по сравнения с Oracle/Microsoft.