Комментарии по теме

«Проверка запросов перед переносом по ландшафту»
Сергей Чаплыгин:
Для того чтобы проверить будут ли проблемы с переносом, например в продуктивную систему необходимо сделать следующее:   1. Запускаем инспектор кода тр. SCI 2. Создаем набор объектов, в...
«Проверка запросов перед переносом по ландшафту»
Олег Табулович:
Спасибо Женя, актуальная тема, полезная статья.
«Проверка запросов перед переносом по ландшафту»
Константин Локшин:
Евгений, добрый день. Очень хорошая статья. Предлагаю вам сравнить вашу программу со стандартной программой для этой цели: /SDF/CMO_TR_CHECK. Насколько я могу судить на текущий момент у...

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

Практический подход к оценке масштабируемости при выборе серверного решения.

11 июля 2012, 16:25

Закупка серверов для внедрения нового решения всегда ставит перед заказчиком достаточно сложную задачу: какую именно конфигурацию необходимо приобрести, чтобы деньги были вложены максимально эффективно. При этом особенно актуально стоит выбор платформы. Здесь всегда хочется соблюсти баланс между «дешевыми» плафтормами типа x86 архитектуры или «дорогими, но надежными» типа RISC (UNIX) архитектуры или мейнфреймов. Таким образом, задача делится на две части: выбор платформы; выбор точной конфигурации.

По второй части задачи нужен комментарий. Если закупить сервер в «полной набивке», точно рассчитанный на существующую сейчас нагрузку, то при росте нагрузки, развитии системы уже через короткое время система перестанет справляться с нагрузками и потребует новых вложений для апгрейдов. С другой стороны, если закупить сервер «на вырост», то часть мощностей будет простаивать и деньги, вложенные в сервер, будут вложены неэффективно. Что делать?

Начнем с выбора платформы.

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

Возьмем пример: вы приходите в магазин, чтобы купить своему маленькому ребенку куртку. Одним из первых факторов, на что вы обратите внимание – это цена, затем вы посмотрите, из какого материала сделана куртка: не порвется, не растянется ли – этим самым вы оцениваете надежность продукта. Вдруг оказывается, что нужного размера нет, можно купить на размер меньше, либо на размер больше, причем на куртку меньшим размером идет небольшая скидка. Какое решение стоит принять? Скорее всего, будет выбран второй вариант: пусть он немного дороже, но не надо будет идти снова в магазин через месяц-другой, да и в тесной куртке ребенок будет мучаться. В нашей аналогии, что ребенок растет и ему в скором времени понадобится новая куртка – мы «отмасштабировали» куртку.

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

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

Понятно, что для решения такой задачи ИТ подразделение должно тесно контактировать с бизнесом для определения стратегии и планов развития. Потребности бизнеса должны быть «переведены» на «язык ИТ». Например, открытие еще одного филиала или внедрение новой системы SCM увеличит нагрузку на инфраструктуру в центральном вычислительном центре на 10%. Еще раз подчеркиваем, что эти цифры должны быть получены именно после анализа стратегий развития и планов, сделанного совместно бизнесом и ИТ. Иначе, откуда взять цифру в 10%?

Продолжим развивать пример с курткой: предположим, вы купили куртку уже себе и весной на выходных решили отправиться на природу на целый день. Ввиду того, что утром на улице оказалось довольно прохладно, вы решили одеть куртку, но днем, когда выглянуло солнце, стало жарко и она оказалась не нужна  - вы убрали ее в сумку. Вечером, когда стало прохладно, пришлось снова одеться. Данный пример очень хорошо показывает чередование условий, при которых условия функционирования системы могут достаточно резко изменяться при штатном режиме работы. В рамках ИТ «смена условий» означает изменение рабочей нагрузки на инфраструктуру, что обозначают термином «пиковые» нагрузки. Они могут быть предсказуемыми и непредсказуемыми. Например, когда с утра сотрудники приходят на работу и прикладывают свои идентификационные карточки к системе регистрации прихода-ухода на работу, нагрузка на эту систему резко возрастает. В течение же рабочего дня нагрузка резко снижается, чтобы опять возрасти в период ухода с работы. Это предсказуемая нагрузка. Можно снять статистические показания в течение определенного периода и неплохо заранее понимать, какова будет нагрузка. Она может иметь суточный, или другой (сезонный) цикл, связанный, например, с периодом массовых отпусков.

А вот если речь идет, например, о системе, обслуживающей банковские карточки, то возможны другие сценарии. Предположим, по рынку внезапно разносится слух о том, что надо срочно снимать деньги. Все клиенты бегут к банкоматам и начинают снимать деньги. Нагрузка на систему внезапно возрастает в разы и может просто привести к остановке системы. Это непредсказуемые нагрузки, с которыми как-то тоже надо бороться и учитывать при расчете масштабирования системы. Или пример с телекоммуникационными операторами: в такие праздники, как Новый Год или Валентинов день, нагрузка возрастает в десятки раз. Что же теперь, закупать систему, которая почти все время будет простаивать, чтобы не «упа сть» два-три раза в году? С другой стороны каждое такое падение может привести к серьезным последствиям: потере клиентов, даже потере бизнеса.

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

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

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

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

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

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

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

Есть еще один аспект, влияющий на выбор нужной конфигурации при учете масштабируемости. Анализ производительности серверов за последние 15 лет показывает, что примерно за 5 лет производительность сервера класса highend сравнивается с производительностью младшего сервера линейки любого вендора. Таким образом, если организация «закладывает» слишком большой ресурс под апгрейд сервера, к тому моменту, когда нужно будет этот апгрейд делать, дешевле уже закупить новый небольшой сервер, который вполне справится с задачей.

Для решения этой задачи при расчете масштабирования помогает специальный инструментарий, так называемое «включение ресурсов по требованию», или в международной терминологии «CapacityUpgradeonDemand». Эти механизмы позволяют изначально закупать ресурсы (например, процессоры, память) в неактивированном состоянии, при этом их начальная стоимость существенно ниже активных процессоров, памяти. В случае необходимости они могут активироваться (в том числе автоматически), и деактивироваться. Оплата идет лишь по использованию этих ресурсов (за день, час, минуту и т.д.). Таким образом наш сервер может как бы мгновенно из сервера среднего уровня «превращаться» в сервер верхнего уровня – и обратно. Это очень удобный механизм, который надо учитывать и применять при решении вопросов масштабирования. 

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

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

Комментарии:

Вячеслав Вишис (Рейтинг: 10) 21:17, 20 июля 2012

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