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

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

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

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

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

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

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

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

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

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

Поэтому фактор масштабируемости систем стоит учитывать не только для долгосрочного