Битва за память. Кто съедает ресурсы?

8 декабрь, 2014 - 17:54Юрий Жуковский

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

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

Избыток вычислительной мощности процессоров стал одним из основных мотиваторов к подтягиванию производительности остальных подсистем сервера. В первую очередь это было надо Intel. Зачем серверам такие мощные вычислители, если остальные подсистемы нивелируют достижения? В какой-то момент, представляя процессоры Xeon на ядре Nehalem, в Intel посчитали, что относительно самого первого поколения Xeon их вычислительная мощность выросла в 175 раз. За то же время производительность дискового I/O поднялась аж на 30%.

Нарастив производительность процессоров и заодно поквитавшись с основным конкурентом, Intel принялась давить на смежников. Снизить задержки обращения к данным по всей цепочке дискового I/O помогли SSD. Они теснят HDD в операционных подсистемах хранения: у самых cкоростных HDD задержки составляют миллисекунды, у SSD — десятки микросекунд. Триумфальный марш SSD в качестве носителя «горячих данных» в пирамиде хранения поднял производительность I/O выше уровня потребностей среднего бизнеса. И это еще дело не дошло до SSD, включаемых непосредственно в шину PCI-express. Еще можно отыскать сегменты, где есть место для подвига — например, биллинговые системы мобильных операторов, но в целом «бутылочное горло» дискового I/O устранено.

Восемь лет назад однопроцессорные платы под Xeon 3000 поддерживали до 8GB памяти DDR2. Пять лет назад в серии Xeon 3400 контроллеры памяти переехали в процессор и стали поддерживать до 32GB DDR3. Xeon E3-1200 остались на той же отметке, зато Xeon E5-1600 подняли теоретический предел до 256GB DDR3, а недавние Xeon E5-1600 v3 — до 768 (!!) GB DDR4. И это только для однопроцессорных серверов.

Следующий резерв производительности — оперативная память (RAM). Какими бы ни были быстрыми постоянные носители, скорость обращения по шинным и дисковым интерфейсам намного медленнее операций в RAM. Та подключена непосредственно к контроллеру процессора, задержки обращения к ней ниже ста наносекунд. При всех рисках размещения данных в энергозависимой памяти, это сильный стимул — cнизить влияние ограничений дискового I/O, уменьшить количество обращений к дискам — за счет расширения адресного пространства оперативной памяти и переноса в нее (части) активных данных.

Высокая скорость доступа и относительно невысокая цена RAM в расчете на гигабайт объясняют рост популярности in-memory applications. В то же время, при переходе от работы с данными на дисках к работе с данными в памяти меняются архитектура систем и структура приложений. Необходимо обеспечить сохранность, состоятельность, устойчивость к ошибкам данных в энергозависимой памяти — за что прежде отвечала дисковая подсистема. Цель того стоит.

Пожиратели RAM

В современной IT-инфраструктуре предприятий самым ненасытным (и агрессивно растущим) едоком RAM является виртуализированная среда. Никуда не делся традиционный потребитель практически любых объёмов оперативной памяти — самые разнообразные базы данных (DB). При очень большом (10К+) числе пользователей и в определенных сценариях работы большой объем RAM может понадобиться под MS Exchange, и даже под Active Directory — хотя в наших условиях такие крупные системы редкость. С распространением сетей доставки контента (CDN) растут аппетиты к памяти кэширующих серверов, раздающих видео по запросу. Аналитики прогнозируют спрос на системы OLAP-in-memory.

Виртуализация

На каждый физический серверный узел может приходиться от считанных нагруженных виртуальных машин (VM) до нескольких сотен небольших VM. Наиболее показательны пограничные случаи:

• основное, критичное бизнес-приложение потребляет 60% и более ресурсов физического хоста;

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

На одном физическом узле может быть запущено несколько виртуальных серверов с «тяжелыми» приложениями — базами данных (DB), или почтовыми системами на сотни пользователей, а также целый набор второстепенных сервисов. Как правило, используется отказоустойчивый кластер на уровне гипервизора (запущен один экземпляр SQL), в ответственных случаях — используется кластеризация на уровне SQL сервера (запущено два экземпляра SQL). При грамотном построении виртуализированной IT-инфраструктуры с 2-3-4 физическими вычислительным узлами средняя загрузка узла желательна на уровне 70-80% по RAM и CPU, при 5 и более средняя нагрузка может достигать 80-90%.

Запуск на одном физическом узле «основной» VM с критичным для бизнеса приложением и нескольких VM c менее важными сервисами — типичный сценарий для средних и крупных компаний. «Основная» VM может съедать 60-90% имеющихся ресурсов RAM хоста. При таких издержках достаточно большим объемом RAM приходится оснащать и вспомогательные серверные узлы — ведь экстренная миграция VM на другой сервер, загруженный своими задачами, не должна приводить к заметному снижению производительности из-за ограничений по памяти. Если VM не сможет мигрировать на соседний узел — придется содержать под нее еще один мощный (дорогой) сервер.

Обслуживание сотен VM — стандартный бизнес провайдеров, предоставляющих в аренду как сами VM под серверы приложений (терминальный доступ, базы данных, почта), так и полноценно развернутые ИТ-инфраструктуры. Как правило, на отказоустойчивом кластере запускаются десятки и сотни виртуальных машин множества клиентов. Распределением физических ресурсов серверов между VM клиентов занимается гипервизор, при ограничениях администратора.

Провайдеры продают виртуальные процессорные ядра (vCPU), виртуальную или конкурентную память (vRAM), такие же гигагерцы и гигабайты. Бизнес-модель строится на оптимизации капитальных затрат («выбрать сервер») и набора арендаторов («гармонизировать нагрузки»). Соотношение числа физических ядер/частоты процессоров/объема оперативной памяти серверов подбирается, исходя из предполагаемых нагрузок и ограничений архитектуры (см врезку). С позиций провайдеров наиболее дефицитным ресурсом является RAM, все платформы-кандидаты оценивается по затратам на обслуживание больших объемов оперативной памяти.

Помогает overselling — продажа большего суммарного виртуального ресурса, чем одномоментно может представить физический сервер. По опыту провайдеров, в современных двухпроцессорных системах память расходуется на 90-100%, при том, что процессоры загружены на 40-70%. Если память наращивать некуда, остается продавать по второму кругу имеющуюся — благо запас по процессорам еще есть. Не покупать же новый сервер.

На сколько пользователей можно разделить ресурсы типичного сервера Microsoft Hyper-V? Для Intel Xeon E5-2650 v2?

• 2 процессора по 8 физических ядер каждый дают в сумме 16 ядер.

• Включение Hyper-Threading делает из них 32 логических ядра.

• Виртуализация системы дает 8 vCPU (можно и больше, к примеру 12, но оптимально до 8) с каждого из 32 логических ядер — итого 256 vCPU.

Эти 256 vCPU можно продать потенциальным покупателям. Хоть 1GB RAM на виртуальное ядро — но выделить надо. И то это в случае если внутри VM будут размещаться пользовательские машины: в Windows 8 в режиме VDI, скажем, 4 vCPU/4GB RAM, будет относительно комфортно. При массовой продаже VM под Windows Server 2012 R2 всего 1GB на 1 vCPU будет явно недостаточно.

Типичные материнские платы под Intel Xeon E5-26xx рассчитаны на установку 16 планок памяти RDIMM или LR DIMM. DDR3 LR DIMM на 32GB непропорционально дороги, да и по латентности нехороши. Максимальная емкость модуля памяти DDR 3 RDIMM — 16GB. В сумме получаем 256GB на сервер — то есть по 1GB на каждый vCPU. Маловато будет.

Варианты есть. Встречаются материнские платы, допускающие установку 24 модулей памяти — до 384GB RDIMM. При установке 6-ядерных процессоров, к примеру высокочастотных Intel Xeon E5-2643 v2 при 8 vCPU на логическое ядро получаем 192 vCPU, и соответственно по 2GB RAM на каждый vCPU.

Можно ставить в серверы 10- и даже 12-ядерные процессоры — увеличивая количество виртуальных ядер на продажу. Чтобы снабдить все ядра памятью, придется перейти на LR DIMM.Суммарный предел для DDR3 LR DIMM составляет 768GB, но за потраченные на память деньги можно купить второй сервер.

Базы данных

В DB-приложениях «много оперативной памяти не бывает».

Специализированные базы данных могут быть изначально рассчитаны на работу из RAM — а значит, помещаться в нее целиком. Пример — интернет-форумы с моментальным доступом к выборке комментариев. Как правило, такие DB невелики по объему (1-10GB, до 50+GB дело доходит редко), зато на одном сервере их может обслуживаться несколько.

Аналитические системы класса OLAP работают с огромными массивами данных. Обычно такие серверы оснащаются 64-128GB памяти, но способны задействовать любую выделяемую RAM под свои нужды: объем реально обрабатываемых в кубах данных может быть гигантским.

Учетная система на базе 1С — стандартный пример OLTP-приложения. Базы данных под 1С объемом в 120-350GB для отечественного бизнеса уже не редкость, встречаются и на 1-3TB. Средняя по масштабу компания на 100-500 пользователей 1С может иметь несколько баз данных объемом в сотни GB, которые эксплуатируются одновременно. Для работы средних по объему баз данных 1С (50+ GB) желательно в RAM кешировать не менее 25-30% их объема, а для больших (1+ TB), где есть данные за длительный период времени (к которым обращаются относительно редко) — хотя бы 10-15% объема. Под SQL-сервер 1С покупают двухпроцессорные системы на 4-8 ядерных процессорах с установкой 128-256GB RAM, а на топовых 10-12 ядерных процессорах — с 256-384 GB RAM.

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

Кроме того, в OLAP-приложениях наборы таблиц данных зачастую можно разнести по различным физическим хостам. Маневр по цене/производительности между наращиванием RAM на одном узле и установкой дополнительных узлов упрощает проектирование и закупку серверов. Некоторые вообще отказываются от собственных систем в пользу облачных сервисов — тому подтверждение тенденция выноса OLAP-аналитики в облака Microsoft Azure и других провайдеров.

Транзакционные системы реального времени (OLTP), традиционно использующие SQL DB — вот истинные ценители RAM. Повышение производительности бизнес-приложениям обеспечивает перенос максимально возможного объема «горячих» данных в RAM-кэш SQL-сервера. Помимо индексов баз данных к «горячим данным» SQL относит наиболее часто используемые блоки таблиц баз данных: актуальные разделы различных справочников, последние записи движения регистров данных и т.д. Чем больше таблиц попадает в RAM-кэш — тем выше скорость обработки запросов. С точки зрения производительности идеально размещение полной копии таблиц баз данных непосредственно в RAM.

Кому еще мало памяти?

На серверы с большим объемом RAM ориентированы основные ИТ-тренды: программно-определяемая инфраструктура, доставка мультимедийного контента, аналитика Big Data.

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

Уже сейчас, по оценкам Intel, средний двухпроцессорный сервер в Европе продается с 256GB RAM. В Украине хорошо если с 64GB RAM.

Поддержка больших объемов RAM (512-768GB) помогла Cisco занять в дата-центрах своими серверами C-series 2 х Intel Xeon E5-26xx нишу куда более дорогостоящих 4-процессорных серверов.

Сети доставки контента (Content delivery networks, CDN) развивают для дистрибуции видео/музыки/фотографий и комфортного социального взаимодействия. Серверы CDN размещаются ближе к потребителю — для снижения времени отклика и расходов на IP-транспортировку. Кеширование файлов массового спроса в оперативной памяти является основной функцией CDN-серверов.

На развитых рынках растет интерес к аналитическим инструментам, построенным на больших данных (Big Data) и самообслуживании (SelfService BI). Переход от классической отчетности к интерактивной бизнес-аналитике повышает оперативность управленческих решений. Аналитика реального времени требует больших вычислительных ресурсов , способных быстро превратить транзакционные данные в выборки бизнес-показателей. Решения in-memory analytics максимально используют возможности RAM и в разы увеличивают скорость обработки данных. В оперативной памяти можно сохранять результаты выполнения запросов, загружать в нее кубы OLAP-сервера, по результатам «температурного анализа» выделять и переносить «горячие» данные во временные аналитические базы данных в памяти.

Фактор лицензирования ПО

Лицензионная политика поставщиков ПО мотивирует пользователей устанавливать в серверы большие объемы оперативной памяти. К примеру, Microsoft Windows Server 2012R2 Datacenter Edition лицензируется «на процессор», при этом количество ядер CPU и объем RAM не имеет значения. Это позволяет запускать на физическом хосте неограниченное количество VM, в каждой из которых Windows Server 2012 автоматически является лицензионной. Аналогичная система лицензирования, на физический сервер и на количество процессоров в системе, применяется в VMWare vSphere.

Такая модель лицензирования ПО выгодна в корпоративном секторе, где IT-инфраструктура в большой степени виртуализирована. Наличие «неограниченного» количества лицензий ОС на физический хост позволяет строить более безопасные и гибкие среды, выделяя практически под каждый сервис отдельную VM (да-да, как похоже на этап перехода от одного универсального сервера к отдельному серверу под каждый сервис). Дробление «один сервис — в отдельной VM» заметно упрощает миграцию сервисов из локальных ЦОД и местами даже «облаков» — в удаленные ЦОД и глобальные облачные сервисы — Microsoft Azure или Amazon.

С другой стороны, эта же модель лицензирования «на процессор» стимулирует Intel производить процессоры со все большим количеством ядер и все большим объемом поддерживаемой RAM.

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