Стратегии масштабирования для приложений ASP.NET - Сходство

Сходство

В конечном счете, сложность эффективного распределения состоит в ликвидации сходства. Например, при наличии только одного веб-сервера хранение на нем данных сеанса вполне понятно. Но где хранить сведения о сеансе при наличии более чем одного веб-сервера?

Один из подходов заключается в хранении их на веб-сервере и использовании сходства. По сути это значит, что первый запрос от определенного пользователя проходит процедуру балансировки нагрузки, но после этого все последующие запросы от данного пользователя/сеанса отправляются на тот же сервер, что и первый запрос. Этот подход прост, его поддерживает каждое решение балансировки нагрузки, и в некоторых случаях он даже осмыслен.

Но в долгосрочной перспективе сходство создает затруднения. Хранение данных сеанса в процессе может быть быстрым, но если рабочий процесс ASP.NET перезапускается, все эти сеансы погибают. А рабочие процессы перезапускаются по множеству причин. При высокой нагрузке IIS может перезапустить рабочий процесс ASP.NET, посчитав его зависшим. Более того, по умолчанию IIS 6.0 перезапускает рабочий процесс каждые 23 часа. Это можно скорректировать, но, так или иначе, пользователям угрожает потеря данных их сеанса, пока они в процессе. Пока веб-узел невелик, это не такая уж проблема, но по мере его роста и увеличения занятости растет и она. И это еще не все.

В случае балансировки нагрузки по IP-адресу один из серверов непременно столкнется с мега-прокси (вроде AOL) и будет неспособен обслужить всю эту нагрузку самостоятельно. Кроме того, перевод серверов на новые версии приложения становится более сложным – необходимо либо ждать часами, пока пользователи закончат операции на веб-узле, либо раздражать этих пользователей, прерывая их сеансы. Становится проблемой и надежность: с потерей сервера теряется масса сеансов.

Устранение сходства является ключевой задачей распределения. Это требует вывода данных о состоянии сеанса из процесса, что означает уменьшение производительности ради увеличения масштабируемости. При выводе сеанса из процесса данные сеанса сохраняются там, где к ним могут получить доступ все веб-серверы – либо в SQL Server®, либо на сервере состояния ASP.NET. Это настраивается в web.config.

Поддержка внепроцессного сеанса также требует определенных усилий по написанию кода. Все классы, которые будут храниться в объекте Session («Сеанс»), следует пометить атрибутом Serializable («Сериализуемый»). Это значит, что все данные в классе должны быть либо сериализуемыми, либо помеченными как NonSerialized («Не сериализуемые»), чтобы класс был проигнорирован. Если не разметить классы, то возникнут ошибки при переносе сеанса сериализатором из процесса в хранилище.

Наконец, вывод сеанса из процесса является отличным способом обнаружить, что в объекте сеанса находится слишком много данных, поскольку теперь пользователю приходится расплачиваться за двукратное перетаскивание этой горы данных туда и сюда по сети (первый раз для получения ее в начале страницы, второй раз для возвращения ее в конце страницы) при каждом запросе страницы.

Разобравшись с объектом сеанса, переходите к другим проблемам сходства, таким как членство и диспетчер ролей. Каждая из них представляет свои сложности при устранении сходства. Но чтобы приложение ASP.NET действительно могло масштабироваться вверх, необходимо отловить все возможные формы сходства и устранить их.

Все стратегии, о которых рассказано к этому моменту, применимы для практически любого веб-приложения, нуждающегося в масштабировании. На самом деле, их можно применить к масштабированию практически любого приложения с использованием любой технологии. Теперь давайте взглянем на некоторые методики, уникальные для ASP.NET.