Руководство по планированию емкости кэша Windows Server AppFabric

Джейсон Рот, Рама Рамани, Хайме Альва Браво

Март 2011 г.

В этом документе представлены рекомендации по планированию емкости Windows Server AppFabric Caching.

1. Введение

2. Оценка производительности кэша AppFabric

3. Методология планирования емкости

   1. Первый этап. Оценка узких мест и выявление кандидатов на использование кэша

   2. Второй этап. Оценка текущих форматов рабочей нагрузки

   3. Третий этап. Оценка физической инфраструктуры и ресурсов оборудования

   4. Четвертый этап. Оформление соглашений об уровне обслуживания в части производительности для всех приложений

   5. Пятый этап. Выбор подходящих компонентов и параметров конфигурации AppFabric

4. Средство планирования емкости

5. Следующие этапы планирования емкости

6. Отслеживание текущих требований к емкости кэша

Введение

Кэш Windows Server AppFabric — это распределенный кластер кэша, размещенного в оперативной памяти. В этом документе представлены рекомендации по планированию емкости для локального развертывания кэша Windows Server AppFabric.

Архитектура кэша Windows Server AppFabric подробно описывается в документации. Дополнительные сведения см. в разделе Компоненты кэша Windows Server AppFabric. В общей сложности кластер кэша AppFabric состоит из одного сервера кэширования или нескольких (она также называются узлами кэша). Кэш равномерно распределяется по узлам кэша и хранится в оперативной памяти.

Примечание

Следует помнить, что продукт Windows Azure AppFabric также позволяет использовать кэш в облачной среде. Некоторые этапы оценки требований к памяти, описанные в этом документе, также применимы к облачному решению, но этот документ в основном относится к локальному кластеру кэша. Дополнительные сведения об использовании кэша Azure AppFabric см. в разделе Кэш Windows Azure AppFabric.

Сведения в этом документе основаны на опыте планирования, собранном корпорацией Майкрософт в ходе работы с клиентами. Все пользователи AppFabric задают похожие вопросы: «Сколько серверов потребуется в нашей среде?» В большинстве случаев обычный ответ — «Это зависит от обстоятельств». Затем мы уточняем различные детали и в итоге приходим к удовлетворительной начальной оценке. В ходе этого процесса часто возникают более специфичные вопросы:

• Сколько памяти кэша потребуется для приложений?

• Сколько компьютеров должно быть в кластере кэша?

• Сколько памяти должно быть на каждом компьютере, и как она должны быть настроены?

• Как пропускная способность сети влияет на производительность кластера кэша?

Задача этого документа — свести воедино результаты обсуждения подобных вопросов с клиентами, чтобы сформировать методологию планирования емкости.

Читая этот документ, вы можете находиться на разных этапах развертывания:

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

2. Возможно, вы уже изучили компоненты и данные о производительности кэша AppFabric. Теперь следует подробно рассмотреть конкретный сценарий и высокоуровневые требования для него. Именно здесь и начинается подробное планирование емкости.

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

Этот документ последовательно рассматривает перечисленные этапы. Для оценки производительности AppFabric можно обратиться к подробному исследованию, составленному нашим партнером Grid Dynamics. Здесь данные этого исследования изложены в упрощенном виде, помогающем провести оценку и планирование емкости.

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

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

Оценка производительности кэша AppFabric

Наш партнер Grid Dynamics недавно завершил серию тестов производительности кэша AppFabric. Результаты тестирования были опубликованы в следующем документе: Кэш Windows Server AppFabric: подробные данные о производительности и масштабируемости.

Каждый тест касался конкретного фактора, будь то размер кэша или число серверов в кластере кэша. Исследование Grid Dynamics помогает оценить производительность и масштабируемость кэша AppFabric. Данные о пропускной способности и задержках из широкого спектра сценариев тестирования и топологий можно сравнить с требованиями для ваших приложений. Обычно в каждом тесте менялся один параметр или два, что позволяло оценить их влияние на производительность. Общий набор параметров:

Шаблон нагрузки.	Шаблон использования кэша, например процентная доля операций Get, Put, BulkGet, GetAndLock и PutAndUnlock.
Объем кэшированных данных.	Объем данных в кэше в момент тестирования.
Размер кластера.	Число серверов в кластере кэша.
Размер объектов.	Размер хранимых в кэше объектов после их сериализации.
Сложность типов.	Различные типы объектов .NET, например byte, string[] и т. д., хранящиеся в кэше.
Безопасность.	Параметры безопасности кластера кэша.

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

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

• Кэш AppFabric линейным образом масштабируется по мере добавления компьютеров в кластер кэша.

• Размер кэша не имеет большого значение, за исключением больших объемов с большой долей операций записи. Помимо прочих факторов, большая доля операций записи в рабочей нагрузке увеличивает интенсивность сборки мусора в .NET при увеличении размера управляемой кучи.

• Повышение сложности типов влияет на производительность только на стороне клиента в силу использования сериализации.

• Массовое извлечение данных повышает эффективность использования сети. Прямой доступ к кэшу лучше использования прокси (ASP.NET, WCF), но это связано с производительностью промежуточного слоя, а не с кэшем.

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

• Уровень безопасности кластера кэша не влияет на производительность; по умолчанию защита включена. Максимальная пропускная способность и минимальные задержки достигаются при отключении защиты, но это может быть недопустимо в силу конфиденциальности данных и действия определенных бизнес-требований.

• Узкие места в сети компенсируются при использовании выделенного сетевого канала между серверами приложений и серверами кэша.

Обратите внимание, что исследование Grid Dynamics хорошо подходит для начальной оценки применимости кэша AppFabric и, кроме того, содержит необработанные данные и выявленные шаблоны, которые можно использовать в процессе планирования емкости.

Методология планирования емкости

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

1. Оценка узких мест и выявление кандидатов на использование кэша

2. Оценка текущих форматов рабочей нагрузки

3. Оценка физической инфраструктуры и ресурсов оборудования

4. Оформление соглашений об уровне обслуживания в части производительности для всех приложений

5. Выбор подходящих компонентов и параметров конфигурации AppFabric

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

Первый этап. Оценка узких мест и выявление кандидатов на использование кэша

Сначала следует понять, какие данные требуется кэшировать. Это можно сделать с помощью таких средств анализа производительности, как профилировщик SQL Server Profiler, системный монитор, тесты в Visual Studioи многие другие. Эти средства позволяют выявить часто используемые объекты баз данных или задержки в вызовах веб-служб. Наборы данных, возвращаемые подобными внутренними хранилищами, могут годиться для кэширования. Временное хранение таких данных в кэше может повысить производительность и снять нагрузку с внутренних хранилищ данных.

После выявления потенциальных кандидатов на кэширование полезно разделить их на три основных категории: данные активности, справочные данные и данные ресурсов. Лучше всего рассмотреть эти категории на примере.

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

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

• Данные ресурсов — это доступные для чтения и записи данные, совместно используемые пользователями. Такие данные могут содержаться, например, на форуме службы поддержки. Все пользователи могут читать публикации на форуме и отвечать на них.

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

Рекомендуется создавать оценки для отдельных объектов и затем свести их воедино. В следующей таблице показан пример сведений, собираемых на этом этапе:

Кэшируемый объект	Категория кэширования	Место постоянного хранения
Объект в корзине	Данные действий	Нет
Объект настроек пользователя	Данные действий	Внутренняя база данных
Каталог продукции	Справочные данные	Внутренняя база данных
Цепочка на форуме	Данные ресурсов	Внутренняя база данных

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

Второй этап. Оценка текущих форматов рабочей нагрузки

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

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

Есть несколько способов уточнить структуру доступа к данным:

1. Тщательный анализ кода с уточнением точек доступа и частоты доступа к данным.

2. Использование профилировщика для определения частоты вызова методов и сбора данных об их производительности.

3. Создание инструментария оценки в коде для отдельных разделов доступа к данным. Попытки доступа к данным заносятся в особый журнал вместе со сведениями о производительности соответствующих операций.

4. Использование профилировщика баз данных, например SQL Server Profiler, для регистрации числа и длительности операций в базах данных.

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

Часть оценки состоит в определении соотношения операций чтения и записи. Это соотношение влияет на принятие решений, касающихся емкости. Так, рабочая нагрузка с большой долей операций записи будет активнее использовать сборку мусора .NET. Это рассматривается далее.

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

Анализируемый объект	Корзина
Доля операций чтения	50%
Доля операций записи	50%
Операций чтения в сек. (максимум)	250
Операций записи в сек. (максимум)	250

Этот анализ опять-таки следует провести для всех типов объектов. Разные типы объектов будут иметь разную структуру доступа и различные показатели чтения и записи при пиковой нагрузке.

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

В примере с веб-приложением ASP.NET рабочие данные могут указывать на то, что в период пиковой нагрузки число пользователей достигает 25 000. У каждого пользователя должны быть данные сеанса, итого получается 25 000 кэшируемых объектов. Срок действия этих объектов можно приравнять к 30 минутам. В периоды пиковой нагрузки рабочие данные могут показывать, что за час появляется 5000 новых пользователей, то есть за получасовой срок действия добавляется 2500 пользователей. Кроме того, некоторые пользователи могут закрыть браузер и начать новый сеанс. Хотя физически это тот же пользователь, при этом будет создан новый сеанс. Это также следует учесть. Наконец, стоит предусмотреть развитие в течение ближайших 6-12 месяцев. Итоговое вычисление максимального числа активных объектов в кэше может иметь следующий вид:

Анализируемый объект:	Корзина
Число пользователей в период пиковой нагрузки	25000
Число новых пользователей за срок действия (30 мин.)	2500
Число имеющихся пользователей, открывающих новые сеансы	250
Оценка будущего роста (25%)	6940
Всего активных объектов (максимум):	около 35 000

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

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

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

Следующие пример кода оценивает средний размер одного объекта. Сериализуемый объект — это obj. Переменная length используется для записи размера. При возникновении проблем с получением размера через NetDataContractSerializer используется BinaryFormatter. Чтобы упростить процесс, код можно преобразовать в отдельный метод. В таком случае obj следует передавать в качестве параметра, возвращая length.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

Примечание

Обратите внимание, что при наличии тестового кластера можно добавлять в кэш объекты и использовать команду Windows PowerShell Get-CacheStatistics для определения размера одного или нескольких объектов в кэше. Также можно разделить общий размер нескольких объектов в кэше на их число. Оценку можно получить как в коде, так и путем тестирования.

Если кэш AppFabric планируется использовать для хранения данных сеансов, важно понимать, что поставщик SQL Server для состояния сеансов ASP.NET всегда использует BinaryFormatter, а не NetDataContractSerializer. Иногда размер объектов, сериализованных классом NetDataContractSerializer, может в несколько раз превышать размер тех же объектов, сериализованных при помощи BinaryFormatter. Это важно в случае, если оценка размера объектов сеансов ведется в SQL Server, так как полагаться на то, что размер этих объектов в кэше будет тем же самым, нельзя. Чтобы получить грубую оценку, можно умножить этот размер на 6. Чтобы уточнить оценку, воспользуйтесь приведенным выше кодом для объекта в данных сеанса. Используя собранные к текущему моменту данные, можно начать формулировать общие требования к объему памяти. Этот этап делится на следующие подэтапы:

1. Выбор типа объекта (например, объект-корзина).

2. Определение среднего размера сериализованного объекта этого типа.

3. Добавление 500 байт к среднему размеру для учета накладных расходов кэширования.

4. Умножение этого числа на максимальное число активных объектов. Это позволяет получить общий объем требуемой памяти в кэше для выбранного типа.

5. Добавьте оценочные накладные расходы на внутренние структуры кэша (5 %).

6. Повторите эти шаги для всех типов объектов.

7. Объедините результаты, чтобы получить общие требования к кэш-памяти.

Обратите внимание, что к оценочному размеру объекта следует добавить около 0,5 КБ на накладные расходы. Также учтите, что в оценку входят внутренние структуры данных кэша. Поддержка областей, тегов и уведомлений требует дополнительной памяти. В примере на эти структуры дополнительно отводится 5 % от общего объема, но этот коэффициент может зависеть от активности использования тех или иных функций кэша.

На этом этапе также следует учесть влияние одной из функций AppFabric — высокого уровня доступности. Эта функция позволяет создавать копии кэшируемых объектов на дополнительных серверах. Это значит, что в случае отказа одного сервера кэширования дополнительный сервер примет на себя нагрузку, и данные не будут потеряны. Если используется высокий уровень доступности, оценку объема памяти следует удвоить. Также следует использовать операционную систему Windows Server 2008 Enterprise или более позднюю версию. Обратите внимание, что высокий уровень доступности включается на уровне именованного кэша. Это значит, что при наличии двух именованных кэшей в кластере необязательно использовать высокий уровень доступности для обоих кэшей. Приложение может поместить часть элементов в именованный кэш высокого уровня доступности, а часть — в обычный именованный кэш. Это позволит оптимальным образом использовать память. В связи с этим важно знать, используется ли высокий уровень доступности, так как он приводит к удвоению объема занятой памяти для кэша.

В качестве примера рассмотрим таблицу с оценкой требований для данных действий и справочных данных в одном и том же приложении. В зависимости от конкретной ситуации можно вести оценку на уровне объекта или на уровне приложения. Достаточно добавить новые столбцы и назвать их соответствующим образом.

Анализируемый объект:	Данные действий	Справочные данные
Средний размер сериализованного объекта:	250 КБ	60 КБ
Накладные расходы кластера кэша на объект	0,5 КБ	0,5 КБ
Скорректированный размер сериализованного объекта:	250,5 КБ	60,5 КБ
Максимальное число активных объектов:	~35000	~68000
Требуемый объем кэш-памяти:	8,4 ГБ	3,9 ГБ
Если используется высокий уровень доступности?	16,8 ГБ	Нет
Накладные расходы на внутренние структуры данных (5 %):	0,8 ГБ	0,2 ГБ
Общий требуемый объем памяти:	17,6 ГБ	4,1 ГБ

Сводка этих оценок даст начальные требования к объему памяти для кластера кэша. В этом примере объем составил 21,7 ГБ. Имея на руках эту оценку, можно рассмотреть другие вопросы, включая физическую инфраструктуру, требования соглашений об уровне обслуживания и параметры конфигурации кэша AppFabric.

Третий этап. Оценка физической инфраструктуры и ресурсов оборудования

Важно понимать физическую инфраструктуру и степень доступности ресурсов. Вот некоторые общие вопросы:

1. Можно ли будет использовать физические компьютеры или виртуальные машины?

2. Какова конфигурация имеющегося оборудования (например, 8 ГБ оперативной памяти, четырехъядерный процессор)?

3. Будет ли кластер кэша располагаться в том же центре обработки данных, что и серверы приложений?

4. Каковы характеристики сети?

Если в качестве серверов кэша планируется использовать виртуальные машины, есть несколько дополнительных факторов. Так, следует учесть влияние размещения нескольких виртуальных машин на одном физическом компьютере. Один сетевой адаптер может совместно использоваться несколькими виртуальными машинами, что снизит сетевую производительность. Кроме того, высокий уровень доступности может быть настроен так, что основной и дополнительный узлы кэша будут размещены в виртуальных машинах на одном компьютере. Если на нем произойдет сбой, копий данных не останется. Дополнительные сведения см. в разделе Рекомендации по использованию виртуальной машины для размещения кэша AppFabric.

Для существующих машин нет рекомендуемых спецификаций. Тем не менее, в крупных кластерах кэша машины с 16 ГБ памяти и четырехъядерными процессорами работают хорошо. В общем случае самые важные вопросы при планировании — это объем физической памяти и сетевая нагрузка.

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

С точки зрения сетевых возможностей следует оценить ожидаемую сетевую нагрузку и соотнести ее с имеющейся инфраструктурой. Во-первых, следует уточнить, сколько данных будет обрабатывать каждый сервер кэша, и достаточны ли для этого ресурсы сетевого адаптера. Если это не так, может потребоваться увеличить число серверов. В качестве примера рассмотрим ситуацию, где средний размер объекта в кэше составляет 500,5 КБ, и в кластере в среднем происходит 240 операций в секунду. Если использовать один узел кэша, результат будет следующим:

Число операций записи и чтения объектов в секунду:	240
Число серверов в кластере кэша:	1
Число операций кэша на сервере в секунду:	240
Средний размер объекта:	500,5 КБ
Объем передаваемых за секунду данных:	240 * 500,5 = 117,3 МБ/сек.

Если каждый сервер оснащен сетевым адаптеров со скоростью 1 Гбит/с, то максимальная пропускная способность составит около 119 МБ/сек. Полученное значение в 117,3 МБ/сек., вероятно, превысит возможности одного сервера. Соответственно, сеть может стать слабым местом кластера. Однако же при использовании трех серверов в кластере с равномерным распределением запросов к кэшу каждый сервер будет получать треть этой нагрузки.

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

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

Четвертый этап. Оформление соглашений об уровне обслуживания в части производительности для всех приложений

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

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

Вот факторы, влияющие на принятие решений:

• Безопасность обеспечивается на уровне кластера кэша. Если пользователь имеет доступ к кластеру, то у него есть доступ ко всем данным в кластере (если пользователь знает имя кэша и ключ для запроса). Если для разных данных требуются разные уровни безопасности, следует использовать несколько кластеров кэша. Дополнительные сведения см. в разделе Управление безопасностью.

• Вытеснение активных объектов происходит, когда память достигает верхнего предела. Неправильная оценка объемов памяти, необходимой для одного кэша, может сказаться на всех кэшах в кластере. Если вытеснение происходит из-за нехватки памяти, то оно проводится во всех кэшах, даже если нехватка памяти вызвана только одним из них. Это можно частично скомпенсировать, создавая кэши без возможности вытеснения, но эту возможность следует использовать аккуратно. Дополнительные сведения см. в разделе Окончание срока действия и вытеснение.

• Наличие нескольких кластеров кэша повышает управляемость лишь до определенного момента. Управлять отдельными кластерами для 100 разных кэшей вряд ли будет просто. Тем не менее, разделить кластеры для двух объемных кэшей может быть разумно, так как это позволит разделить управление, масштабирование и мониторинг.

Наконец, часть требований касается задержек и пропускной способности. Чтобы принять осознанное решение, обратитесь к исследованию Grid Dynamics за советами и результатами тестов. Например, можно сравнить требования по пропускной способности кластера кэша с результатами тестов в исследовании Grid Dynamics. Это позволит определить, достаточно ли серверов для достижения поставленных целей. Важно учесть, что исследование может не всегда в точности повторять типы объектов, их размеры, а также физическую и логическую инфраструктуру. Тем не менее, в нем приведены подтвержденные результаты тестирования, которые могут помочь принять осознанное решение.

Пятый этап. Выбор подходящих компонентов и параметров конфигурации AppFabric

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

В следующей таблице перечислены компоненты и функции кэша AppFabric, а также соответствующие вопросы планирования емкости.

Области	Можно создать несколько областей, но каждая будет располагаться только на одном сервере. Чтобы использовать преимущества распределенного кэша, приложения должны использовать несколько областей. Обратите внимание, что все вызовы без явного указания области автоматически относятся к областям по умолчанию. Каждый узел кэша в кластере должен быть способен принять самую крупную область наибольшего размера.
Уведомления	Кэши поддерживают уведомления, которые получают клиенты кэша. Их использование ведет к росту сетевого трафика и загрузки процессора на стороне сервера. Степень влияния зависит от интервала отправки уведомлений и их числа. Высокое число уведомлений с кратким интервалом может снизить производительность и масштабируемость. Четких правил оценки влияния этого фактора не существует, поэтому его следует учесть при тестировании.
Локальный кэш	Локальный кэш повышает производительность за счет того, что объекты кэшируются и на клиенте, и на сервере. При использовании этой функции следует учесть ее влияние на память на клиентских компьютерах. Эта функция не влияет на серверную память, так как все элементы в локальном кэше также есть и на сервере. Тем не менее, если для объявления о недействительности локального кэша используются уведомления, то сервер будет вынужден обрабатывать уведомления, что даст свой эффект.
Архитектура и конфигурация клиентских приложений	Архитектура клиентских приложений может сказаться на общей производительности. Так, все создаваемые объекты DataCacheFactory следует хранить для повторного использования, а не создавать заново для каждого вызова. Разумно будет создать по одному объекту DataCacheFactory на каждый поток. Если же один объект DataCacheFactory используется несколькими потоками, попробуйте увеличить значение параметра MaxConnectionsToServer. Это позволяет увеличить число подключений к серверам кэширования для одного объекта DataCacheFactory.
Высокий уровень доступности	Как уже говорилось, кэши высокого уровня доступности нуждаются в двойном объеме памяти. Также для этой функции требуется не менее трех серверов. Если один откажет, два оставшихся сервера смогут играть роли основного и дополнительного узла для хранения копий элементов после сбоя. Обратите внимание, что для использования этой функции на всех серверах должна использоваться система Windows Server 2008 Enterprise или более поздняя.
Именованные кэши	Сейчас существует ограничение — можно использовать не более 128 именованных кэшей. Это влияет на ситуацию, когда приложениям нужно большее число именованных кэшей. В настоящее время в такой ситуации придется использовать несколько кластеров кэша или сократить число кэшей, требуемых для приложений. Еще одна стратегия — программное создание областей в именованных кэшах.
XML-хранилище конфигурации	При использовании общего сетевого ресурса для хранения конфигурации кластера кэша в кластере должно быть не менее трех серверов, настроенных в качестве ведущих узлов. Дополнительные сведения о причинах см. в разделе Обновление серверов кэша.

Вряд ли кого-то удивит, что один из самых важных факторов — это параметры памяти на узлах кэша. Их можно просмотреть на каждом узле с помощью команды Windows PowerShell Get-CacheHostConfig.

Примечание

Сведения об использовании команд кэширования в Windows PowerShell см. в разделе Часто выполняемые действия по управлению кластером кэша.

На следующем снимке экрана показаны выходные данные команды Get-CacheHostConfig на компьютере с 4 ГБ памяти.

По умолчанию объем памяти, отведенной для кэша на сервере, составляет 50 % ее общего объема. В этом примере объем составил 2 ГБ. Оставшаяся память доступна для самой операционной системы и служб в ней. Даже на компьютерах с гораздо большим объемом памяти изменять этот параметр не рекомендуется. Как упоминалось ранее, служба кэша рассчитана на выделенный сервер и может использовать больше памяти, чем ей отведено. Хотя это частично вызвано устройством самой службы, это также связано с тем, как в .NET ведется сборка мусора и управление памятью. Даже если приложение .NET освобождает память, для ее окончательного освобождения должна пройти сборка мусора. В связи с недетерминистической природой сборки мусора процессам требуется поддерживать буфер физической памяти.

Осознав влияние сборки мусора, можно увидеть, что рабочие нагрузки с высокой долей и частотой операций записи будут нуждаться в увеличении объема упомянутого буфера, чтобы процесс мог справиться с обработкой мусора. Нагрузок, в основном связанных с чтением, это не касается. В этом случае иногда можно увеличить объем памяти, отведенной для кэша. Например, на компьютере с 16 ГБ памяти можно изменить параметр Size и отвести 12 ГБ на кэш (вместо обычных 8 ГБ), оставив 4 ГБ на ОС и другие службы. Здесь подразумевается, что компьютер выделен под службу кэша — сейчас это единственный поддерживаемый вариант. В данном примере конфигурацию памяти следует протестировать с предполагаемой нагрузкой. Если выделение памяти идет слишком агрессивно, это будет выявлено в ходе тестирования на таких аспектах работы с памятью, как вытеснение или регулирование. Дополнительные сведения см. в разделе Устранение неполадок сервера (кэширование Windows Server AppFabric). В следующем примере команда Set-CacheHostConfig используется для задания размера кэша в 12 ГБ на сервере Server1.

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

Другой важный момент в выходных данных Get-CacheHostConfig — это значения пределов. Значение LowWatermark по умолчанию составляет 70 % от размера кэша (параметр Size). Когда объем памяти кэша достигает значения LowWatermark, служба кэша начинает вытеснять объекты с истекшим сроком действия. Это вполне нормально, так как эти объекты все равно недоступны.

Значение HighWatermark по умолчанию составляет 90% от размера кэша. При достижении уровня HighWatermark объекты вытесняются вне зависимости от того, истек ли срок их действия, пока объем памяти не вернется на уровень LowWatermark. Очевидно, что это может сказаться на производительности и (в итоге) на пользователях.

Рекомендуется планировать загрузку кэша на уровне значения LowWatermark, чтобы избежать достижения значения HighWatermark. Дополнительные сведения см. в разделе «Окончание срока действия и вытеснение».

Совет

Полный цикл сборки мусора может вызывать небольшие задержки, которые часто приводят к ошибкам с необходимостью повтора действий. По этой причине рекомендуется не превышать на узлах кэша объем памяти в 16 ГБ. Компьютеры, где используется свыше 16 ГБ памяти, могут вызывать более длительные паузы при полной сборке мусора. Помимо этого, ограничений на увеличение объемов памяти на узлах кэша нет. Нагрузка, связанная только с чтением, может не вызывать полных циклов сборки мусора с заметной частотой. Это лучше всего выясняется при тестировании.

В предыдущем примере мы вычислили, что общий объем памяти кэша должен составлять 21,7 ГБ. Так как нам нужен высокий уровень доступности, потребуется не менее трех серверов. Предположим, что на каждом есть по 16 ГБ памяти. В этом примере значение параметра кэша Size останется без изменений — по 8 ГБ на сервер. Как упоминалось выше, следует равняться на уровень LowWatermark — 70 % от общего объема памяти на каждом сервере. Это значит, что на каждом сервере кэширования будет примерно по 5,6 ГБ памяти. С учетом всех этих рассуждений в следующей таблице показано, что четыре сервера обеспечат 22,4 ГБ памяти для кэша, что покроет потребность в 21,7 ГБ.

Общий требуемый объем памяти	21,7 ГБ
Физическая память (узел кэша)	16 ГБ
Параметр кэша Size (узел кэша)	8 ГБ
Нижний предел (узел кэша)	70%
Скорректированный требуемый объем памяти на узле кэша	5,6 ГБ
Общий объем памяти в кластере кэша (4 компьютера)	5,6 ГБ * 4 сервера = 22,4

Снова следует напомнить, что можно воспользоваться результатами исследования Grid Dynamics, чтобы подтвердить свои оценки пропускной способности и задержек. Это может привести к корректировке начальных оценок, например, путем добавления дополнительного сервера кэширования. Важно использовать для принятия решения все доступные ресурсы.

Средство планирования емкости

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

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

Важно!

Если не использовать значения установки по умолчанию, следует запустить команду Set-CacheHostConfig на всех узлах кэша, чтобы узнать значения параметров CacheSize и LowWatermark.

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

Третий раздел касается требований к сети. Следует указать средний размер записываемых и считываемых объектов, а также максимальную частоту этих операций. Этот раздел вычисляет максимальную требуемую пропускную способность для указанного типа объектов. Эти данные можно использовать для приблизительной оценки способности имеющейся сетевой инфраструктуры справиться с нагрузкой. Как говорилось ранее, также следует оценить пропускную способность сетевого пути. Третий раздел показан на следующем снимке экрана.

В последнем разделе сведены требования к объему памяти и пропускной способности сети. Указанная в первом разделе конфигураций компьютера используется для вычисления числа серверов. Поле «Дополнительные серверы» позволяет увеличить число серверов при необходимости. Например, если вычисления показали, что требуется лишь два сервера, можно добавить к результату третий сервер, чтобы обеспечить высокий уровень доступности. Последний раздел показан на следующем снимке экрана.

Примечание

На приведенных снимках используются показатели, аналогичные приведенным выше, но оценочное число серверов — три, а не четыре. Причина в том, что в таблице для параметра Cache Size Setting(Set-CacheHostConfig) задано значение 12 GB — это позволяет продемонстрировать эффект изменения этого параметра. Изменив значение на 8 GB, можно получить результаты, аналогичные приведенным выше.

Следующие этапы планирования емкости

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

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

Отслеживание текущих требований к емкости кэша

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

Системный монитор — лучшее средство для текущего наблюдения за емкостью. На каждом узле кэша требуется следить за следующими счетчиками:

Категория	Счетчики системного монитора
Память	AppFabric Caching:Host\Общий объем данных в байтах AppFabric Caching:Host\Общее число вытесненных объектов AppFabric Caching:Host\Общее число запусков вытеснения AppFabric Caching:Host\Общий объем вытесненной памяти AppFabric Caching:Host\Общее число объектов .NET CLR Memory(DistributedCacheService)\Сборов "мусора" для поколения 0 .NET CLR Memory(DistributedCacheService)\Сборов "мусора" для поколения 1 .NET CLR Memory(DistributedCacheService)\Сборов "мусора" для поколения 2 .NET CLR Memory(DistributedCacheService)\Закрепленных объектов .NET CLR Memory(DistributedCacheService)\% времени в GC .NET CLR Memory(DistributedCacheService)\Размер кучи для массивных объектов .NET CLR Memory(DistributedCacheService)\Размер кучи поколения 0 .NET CLR Memory(DistributedCacheService)\Размер кучи поколения 1 .NET CLR Memory(DistributedCacheService)\Размер кучи поколения 2 Memory\Доступно МБ
Сеть	Network Interface(*)\Получено байт/сек Network Interface(*)\Отправлено байт/сек Network Interface(*)\Текущая пропускная способность
Процессор	Process(DistributedCacheService)\Загруженность процессора Process(DistributedCacheService)\Число потоков Process(DistributedCacheService)\Рабочий набор Processor(_Total)\Загруженность процессора
Пропускная способность	AppFabric Caching:Host\Общее число запросов клиентов AppFabric Caching:Host\Общее число запросов клиентов в сек. AppFabric Caching:Host\Общее число запросов Get AppFabric Caching:Host\Общее число запросов Get в сек. AppFabric Caching:Host\Общее число запросов Get AppFabric Caching:Host\Общее число запросов Get в сек. AppFabric Caching:Host\Общее число запросов GetAndLock AppFabric Caching:Host\Общее число запросов GetAndLock в сек. AppFabric Caching:Host\Общее число запросов чтения AppFabric Caching:Host\Общее число запросов чтения в сек. AppFabric Caching:Host\Общее число операций записи AppFabric Caching:Host\Общее число операций записи в сек.
Прочее	AppFabric Caching:Host\Процент промахов кэша AppFabric Caching:Host\Общее число просроченных объектов AppFabric Caching:Host\Общее число доставленных уведомлений

Многие перечисленные счетчики напрямую связаны с процессом планированием емкости. Например, здесь есть несколько счетчиков памяти. Счетчик «Memory\Доступно МБ» демонстрирует, сколько физической памяти доступно на компьютере (в МБ). Если значение этого счетчика становится ниже 10 % от общей физической памяти, возможен запуск регулировки. Дополнительные сведения см. в разделе Устранение неполадок регулирования. Другие счетчики относятся к функциям кэша. Счетчик «AppFabric Caching:Host\Общее число запусков вытеснения» указывает, как часто запускается вытеснение. Когда объем памяти превышает верхний предел, этот счетчик будет указывать на запуск вытеснения с целью возврата объема памяти к нижнему пределу. Прочие счетчики аналогичным образом связаны с процессом планирования емкости, описанным в предыдущих разделах.

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

Помимо системного монитора, можно использовать команды Windows PowerShell из комплекта AppFabric. Многие из этих команд можно использовать для наблюдения за работоспособностью и состоянием кластера кэша. Дополнительные сведения см. в разделах Средства наблюдения за работоспособностью и Ведение журнала и счетчики кэша AppFabric.

См. также

Другие ресурсы

Установка Windows Server AppFabric
Документация по кэшированию Windows Server AppFabric в MSDN
Руководство по программированию для кэша AppFabric
Настройка поставщика состояний сеансов ASP.NET
Варианты хранения конфигурации кластера кэша
Руководство по развертыванию кэширования и управлению им в Windows Server AppFabric
Ссылки и ресурсы по Windows Server AppFabric и Windows Azure AppFabric

  2011-12-05