Как часть своей платформы для веб разработки Microsoft предоставляет и NoSQL решение для кэширования — AppFabric Cache. Одним из интересных режимов AppFabric Cache является High Availability — возможность создать кластер из кэш-серверов где в случае падения любого из них работа вашей службы не прерывается и все данные остаются доступными приложению. Когда вы создаете .NET веб-приложение без единой точки сбоя (single point of failure), использование такого кэш сервера кажется легким и естественным решением. Особенно здесь может радовать цена, так как AppFabric предоставляется компанией Microsoft бесплатно как часть своей операционной системы. Однако выбирая решение для кэширования полезно видеть не только то что на поверхности.
Когда вы включаете режим High Availability для любого объекта в кэше есть два экземпляра на разных серверах кластера, так что потеря одного сервера не приведет к потери данных:
(из документации msdn.microsoft.com/en-us/library/ee790974.aspx)
Такая конфигурация ничего не требует от приложения, API точно такой же как если кэш работает без High Availability. Таким образом вы можете хранить данные сессии в таком кэше при помощи встроенного провайдера и получить возможность масштабирования приложения и устойчивость к сбоям без написания единой строчки кода.
И хотя это выглядит довольно интересно, есть ряд моментов которые лучше знать до того как разворачивать готовое приложения заточенное под AppFabric на production серверах:
AppFabric кластер в режиме High Availability будет работать с двумя компьютерами, но не будет работать с одним. Поэтому если вы избавляетесь от единой точки сбоя, вам нужно как минимум 3 компьютера, чтобы в случае потери одного из них работа вашей службы не остановилась бы.
Посмотрите есть ли у вашего хостинг провайдера Enterprise Edition в списке образов или можно воспользоваться особыми программами Microsoft на получение лицензий для стартапов (http://www.microsoft.com/bizspark/).
Можно решить что раз у вас есть копии объектов на других компьютерах служба будет работать без перерыва, так? Нет, нет совсем. Правило работы службы говорит о том что копии объектов должны быть как минимум на двух узлах кластера. Когда один из узлов становится недоступным объекты копии которых существуют в единственном экземпляре будут копироваться на другие узлы кластера пока все объекты не будут представлены в двух экземплярах. Пока объекты будут копироваться ваша служба будет не доступна.
В частности это значит что вы не можете безопасно перегрузить один из компьютеров кластера AppFabric поскольку в работе службы будет некоторый перерыв.
Это будет большей проблемой если ваши узлы содержат много оперативной памяти ведь тогда копирование будет более долгим. Чтобы минимизировать эту проблему лучше держать больше серверов с меньшим количеством RAM.
Все узлы кластера используют общую конфигурацию, которую можно содержать или на файловой шаре или на MSSQL сервере. Если вы разворачиваете службу в режиме High Availability чтобы избавится от единой точки сбоя, то использовать файловую шару довольно глупо, недоступность компьютера с конфигурацией остановит работу кэша. Но вот сюрприз — когда вы настраиваете конфигурацию на SQL сервере утилиты конфигурации не дают вам это сделать требуя чтобы ваш сервер входил в Windows домен.
Что же делать?
Все это довольно грустно и могло быть фейлом №1 для High Availablity, но к счастью можно найти и более простое решение, если на всех компьютерах кластера завести Windows account с одинаковым именем и паролем (account mirroring). Такую конфигурацию можно провести с помощью AppFabric Powershell Console, штатная GUI программа для настройки кластера не позволит вам это сделать.
Как это работает
Когда вы включаете режим High Availability для любого объекта в кэше есть два экземпляра на разных серверах кластера, так что потеря одного сервера не приведет к потери данных:
(из документации msdn.microsoft.com/en-us/library/ee790974.aspx)
Такая конфигурация ничего не требует от приложения, API точно такой же как если кэш работает без High Availability. Таким образом вы можете хранить данные сессии в таком кэше при помощи встроенного провайдера и получить возможность масштабирования приложения и устойчивость к сбоям без написания единой строчки кода.
И хотя это выглядит довольно интересно, есть ряд моментов которые лучше знать до того как разворачивать готовое приложения заточенное под AppFabric на production серверах:
Для работы High Availability требуется иметь минимум 3 сервера
AppFabric кластер в режиме High Availability будет работать с двумя компьютерами, но не будет работать с одним. Поэтому если вы избавляетесь от единой точки сбоя, вам нужно как минимум 3 компьютера, чтобы в случае потери одного из них работа вашей службы не остановилась бы.
Для работы High Availability требуется чтобы все компьютеры были Windows 2008/2008R2 Enterprise Edition (или выше)
Посмотрите есть ли у вашего хостинг провайдера Enterprise Edition в списке образов или можно воспользоваться особыми программами Microsoft на получение лицензий для стартапов (http://www.microsoft.com/bizspark/).
Предположим что у вас есть кэш-кластер из 3 компьютеров, что происходит когда когда один из этих компьютеров внезапно выходит из строя?
Можно решить что раз у вас есть копии объектов на других компьютерах служба будет работать без перерыва, так? Нет, нет совсем. Правило работы службы говорит о том что копии объектов должны быть как минимум на двух узлах кластера. Когда один из узлов становится недоступным объекты копии которых существуют в единственном экземпляре будут копироваться на другие узлы кластера пока все объекты не будут представлены в двух экземплярах. Пока объекты будут копироваться ваша служба будет не доступна.
В частности это значит что вы не можете безопасно перегрузить один из компьютеров кластера AppFabric поскольку в работе службы будет некоторый перерыв.
Это будет большей проблемой если ваши узлы содержат много оперативной памяти ведь тогда копирование будет более долгим. Чтобы минимизировать эту проблему лучше держать больше серверов с меньшим количеством RAM.
Конфигурация
Все узлы кластера используют общую конфигурацию, которую можно содержать или на файловой шаре или на MSSQL сервере. Если вы разворачиваете службу в режиме High Availability чтобы избавится от единой точки сбоя, то использовать файловую шару довольно глупо, недоступность компьютера с конфигурацией остановит работу кэша. Но вот сюрприз — когда вы настраиваете конфигурацию на SQL сервере утилиты конфигурации не дают вам это сделать требуя чтобы ваш сервер входил в Windows домен.
Что же делать?
- Обеспечить возможность бесперебойной работы файловой шары при помощи возможностей Windows 2008R2 Сluster
- Развернуть контроллер домена в вашей серверной среде. Учтите что на сам домен контроллер вы не сможете поставить AppFabric Cache. Кроме того ваш контроллер домена будет новой потенциальной точкой сбоя.
- Написать своего собственного провайдера для хранения конфигурации.
Все это довольно грустно и могло быть фейлом №1 для High Availablity, но к счастью можно найти и более простое решение, если на всех компьютерах кластера завести Windows account с одинаковым именем и паролем (account mirroring). Такую конфигурацию можно провести с помощью AppFabric Powershell Console, штатная GUI программа для настройки кластера не позволит вам это сделать.
Throttling
AppFabric Cache использует оперативную память для кэширования. Когда в счетчике Memory\Available MBytes памяти меньше чем 15% от размера физической памяти компьютера, то узел переходит в состояние Throttled. В этом состоянии запись новых данных на этом хосте невозможна. Следует помнить при планировании ресурсов.Выводы
- Хотя сама служба AppFabric Cache бесплатна, для работы High Availability требуется серверная операционная система с редакцией Enterprise Edition или выше, а также как минимум 3 компьютера.
- High Availability на практике оказывается не столь уж High раз потеря одного узла приводит к временной недоступности всего кэша и возможно вашего приложения, если вы специально не предусмотрели сценарий работы приложения при недоступном кэше. Тем ни менее работа службы восстановиться сама без потери данных через некоторое время. Допустимо ли это в вашем приложении решать вам, но лучше знать об этом до того как вы плотно завяжитесь на использование данного продукта.