среда, 13 апреля 2011, Малеев Дмитрий

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

Какой-то непонятный сонник(с)

---

Да,мы уже много с вами говорили, о том что любое облако - это очень много копмьютеров, при том Ваше приложение может находиться на одном копмьютере, или на десяти, или даже на 100. К примеру в 2008 году у facebook было уже 10000 серверов. Сколько есть сейчас - даже боюсь представить. Важно понять, что если у Вас 1 приложение, оно должно уметь работать, зная что запрос может прийти необязательно на одну и ту же машину. Юзер может залогироваться в приложение, при этом риквесты пойдут на машину номер 234, а когда уже тыкнет на кнопочку - то риквесты могут идти уже на машину 15! Иногда машины горят, потому приложение должно быть готово и к таким ситуациям - не обязательно что риквест от одного пользователя прийдет на туже машину дважды!

Как оно все работает?

Элементарно. Все запросы на самом деле идут не прямо на Ваше приложение, а к такому парню как Network Load Balancer. Он знает про все ваши веб роли ( точнее сказать про все инстансы Вашей веб роли), и знает кто как загружен. Анализируя эти данные балансер перенаправляет запросы на самую не загруженную ноду.

Ну что, давайте смотреть как оно там все работает? Итак, чтобы посмотреть как Network load balancer распаралеливает запросы по инстансам веб роли, начнем с того что создадим обычное тестовое приложение.

1. Создаем новый Cloud проект.
2. В нем создаем обычную ASP.Net web role.
3. Добавляем на страничку кнопку Кнопка будет делать - Вы угадали - ничего:) На самом деле кнопка нам нужна, только для того чтобы перегружать страничку. В метод Page_Load же мы добавим написания данных в лог:

        /// <summary>
        /// Handles the Load event of the Page control.
        /// </summary>
        /// <param name="sender">The source of the event.</param>
        /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param>
        protected void Page_Load(object sender, EventArgs e)
        {
            System.Diagnostics.Trace.WriteLine("Wow! I am writening to log!", "Information");   
        }

Собственно, каждый раз когда мы будем нажимать на кнопку, в лог будет писаться сообщение. Теперь увеличиваем количество инстансов нашей веб роли до двух:

<ServiceConfiguration serviceName="WindowsAzureProject2" 
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
osFamily="1" osVersion="*">
  <Role name="TestRole">
    <Instances count="2" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 
value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

Теперь запускаем, и яростно нажимаем кнопку! Смотри на Compute Emulation UI. Вы увидете что у вас есть два инстанса, в каждый з которого будет что-то да писаться. Если быть честным, то у меня все риквесты шли в один инстанс, но я верю, что если его нормально подгрузить, то риквесты будут идти на разные инстансы.

Итак, что мы получили - мы получили возможность проверить наше приложение на то , как оно будет работать в присутствии network load balancer и даже , что не маловажно, с дебаггером. Гораздо труднее будет искать баги, когда ваше приложение уже будет крутиться в продакшене.

Все это счастье стает возможным при работе небольшорй тулхзы под названием: DFLoadbalancer. Его можно увидеть в таск менеджере. Также очень советую обратить внимание на процессы под названием: WaHostBootstrapper. Обратите внимание что количество этих процессов равно количество инстансов ваших веб ролей. Если вы закончите этот процесс, то веб роль будет перезагруженна, и все риквесты которые раньше шли на эту роль будут перенаправленны на другие роли - с помощью этого метода Вы можете протестировать как Ваше приложение будет вести себя в случае потери одного бойца:)

Ну что, теперь когда мы знаем как и куда редиректит запросы Network Load Balancer , давайте обгорим несколько проблем, которые возникают при распределении нашего приложения на несколько машин.

Первый вопрос - Сессия. Ну че, удобная штука, записал в сессию какое - нибудь значение, и вытаскиваеш его тогда, когда тебе надо. Проблема в том, что сессия живет в памяти сервера - а как мы уже говорили, не факт что запрос прийдет два раза подряд на одну и ту же машину.

Даже если вы используете одну машину могут возникнуть проблемы отключения тачки. Допустим сервер на которой висела виртуалка облили кофем - он обиделся и згорел. Ажур сразу же восстановит Вашу веб роль на другой виртуалке, и пользователи смогут опять использовать Ваше приложение, но сессия к тому времени уже будет потерянна, ибо она жила в памяти погибшей виртуальной машины.

Опять же таже проблема распаралеливания риквестов. Представим что пользователь залогировался в Ваше приложение, и какое - то время пользовал его. Вы запомнили имя пользователя в сессии, и приложение знаете что и почему дозволенно пользователю. Допустим, залогировалось ещё несколько пользователей, и серве стал более загружен. Network Load Balancer зная что это случилось, начинает перенаправлять запросы этого пользователя на новую машину, где сессии нету, и скорее всего пользователя попросит залогироваться ещё раз. А представте что его сновы перенаправит на другую машину - я думаю пользователь будет разочерован и возмущен, и больше никогда - никогда не вернется в Ваше приложение. Ну и собственно проблема памяти - сессия хранится в памяти, потому чем больше вы туда будете записывать информации, тем быстрее сломаете виртуалку:)

Я описал проблемы которые могут возникнуть при стандартном использовании сессии, и стандартных настройках, что называется In-Proc Session Management.

Давайте поговорим, как же использовать сессию в Ажуре? С этой проблемой я столкнулся ещё 2 года назад, когда был участником оффшор комманды для стартап - инкубатора в Атланте. Тогда возник вопрос о существовании сессии в Ажуре. Очень отлично то - что можна создавать свои собственные провайдеры сессии. Как реккомендуют все книжки, и как реккомендую я - использовать стоит Azure Tables. Для того чтобы реальзовать это, нужно сделать всего лишь несколько вещей: 1. Пойти по этой линке : http://archive.msdn.microsoft.com/windowsazuresamples
2. Скачать примеры.
3. Запустить buildme.cmd
4. Добавить ссылку на полученную библиотеку в Вашем проекте.
5. Добавить следующую конфигурацию в web.config

<sessionState mode="Custom"
        customProvider="TableStorageSessionStateProvider">
    <providers>
      <clear/>
      <add name="TableStorageSessionStateProvider"
      type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider"
      allowInsecureRemoteEndpoints="false"
      accountName="devstoreaccount1"
      sharedKey="Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="
      containerName="sessionstate"
      applicationName="ProviderTest"
      blobServiceBaseUri="http://127.0.0.1:10000"
      tableServiceBaseUri="http://127.0.0.1:10002"
      sessionTableName="Sessions" />
    </providers>
  </sessionState>

В данной конфигурации девелоперский аккаунт на вашей машине будет использован для хранения данных. Когда Вы будете идти в продакшен, вам будет необходимо использовать конфигурацию ваших сервисом хранения данных.

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

Сразу признаюсь - скорость получения данных с табличек немного меньше чем скорость работы сессии из памяти.

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

Во многих сайтах используется две прослойки кеша: 1. In-Process Caching 2. Distributed Caching

In-Process caching - эти слой обычно содержит в себе статичные данные которые очень редко изменяются. Например ваше приложение показывает рейтинг банков раз в месяц. Высчитывается все это по сложной формуле, которая запускается раз в месяц, и крутиться она по 2 часа. Такие данные логичнее всего кэшировать в базе данных или табличках. Конечно все зависит от типа данных, но я бы реккомендовал вам использовать таблички, просто потому что это во много раз дешевле. Сравните: Azure Storage - $0.15 per GB stored per month SQL Azure - $9.99 per database up to 1GB per month

для того чтобы хранить данные, которые могут меняться чаще, и должны быть доступны для большой кучи серверов, стоит использовать механизм Distributed Caching. Для того чтобы реализовать этот механизм - чаще всего используют такую штуку как memcached. Это опенсорсный провайдер кэширования который был разработан для livejournal. Собственно - в двух словах - это огромнейшая хэш табличка, которая доступна всем серверам в сети.

Для того чтобы нам бло проще, Microsoft выпустила приложение которое ускоряет работу memecached механизма - под названием Memcached Solution Accelerator.

Скачать Windows версию memcached можна по данной линке: http://wiki.membase.org/display/membase/Membase+for+Memcached+Users

Memcached Solution Accelerator можна скачать тут:http://archive.msdn.microsoft.com/winazurememcached

После того как вы добавите Memcached в Вашу систему, для записи данных стоит использовать следующий синтаксис:

AzureMemcached.Client.Store(StoreMode.Set, key, value);  

Для получения данных стоит использовать следующий код:

AzureMemcached.Client.Get(key);

Кстати в Azure будет свой кэш сервис в AppFabric.

Вот инфа с портала: Caching provides a distributed, in-memory, application cache service for Windows Azure and SQL Azure applications. It provides applications with high-speed access, scale, and high availability, to application data. These capabilities are provided entirely as a service (no installation or management of instances, dynamically increase/decrease cache size as needed).

И самое главное, что: Today, Caching is available for developer preview only, as part of our Previews environment. General availability of the service is planned for the 1st half of 2011.

Следовательно очень скоро мы можем ожидать релиза данной фичи, которая безусловно облегчит нам жизнь!

Также в ASP.Net 4.0 появился кешинг провайдер который разрешает настроить нам кэш который будет храниться в облаках , не только для приложений которые живут в облаках! Так же , очень удивлися когда узнал про существование такого продукта,как Velocity. С помощью этой штуки мы можем создавать кеш провайдеры которые будут использовать memcache без лишних танцев с бубном, стоит только добавить такой кусок конфигурации:

 <system.caching>
    <cache defaultProvider="FrameworkCacheProvider">
      <providers>
        <add name="myVelocityInstances"
        type="System.Data.Caching.VelocityCacheProvider,System.Data.Caching”"
        remoteServerName="myServer"
        remoteServerPort="4435"
        namedCache="myCache"
        securityToken="DEC3D34CA29112" />
      </providers>
    </cache>
  </system.caching>

Как видим средств использования как кеша так и сессии достаточно много - стоит только покопать:)

Полезные ссылки: http://memcached.org/ портал memcached. Очень доступно и интересно описанно http://ru.wikipedia.org/wiki/Memcached - memcached ru wiki!

http://blogs.msdn.com/b/velocity/ - домашняя страничка пордукта Velocity http://blogs.msdn.com/b/mcsuksoldev/archive/2010/02/04/9958494.aspx - отличный пост о том как прикрутить memcached в Ажуре. http://archive.msdn.microsoft.com/winazurememcached - Windows Azure Memcached Solution Accelerator

http://www.microsoft.com/windowsazure/appfabric/overview/default.aspx#top - внутренний механизм кэширования в Ажуре

http://netindonesia.net/blogs/wely/archive/2010/09/22/implementing-session-state-management-in-windows-azure-with-azure-storage.aspx - Implementing Session State Management in Windows Azure with Azure Storage

---