Варианты математического аппарата для описания проблем масштабирования динамической инфраструктуры

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

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

F(v) = G(f 1(v), f 2(v),..., f p(v))

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

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

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

Для формального описания системы обозначим через Х все множество альтернативных решений, q_j – значения критериев (уровни притязаний), а точку их пересечения в р-мерном пространстве критериев х* - целью или опорной точкой. Важно отметить, что целевая точка может оказаться как внутри, так и во вне Х, т.к. уровни притязаний задаются без точного знания структуры множества Х в пространстве частных критериев. Идея оптимизации состоит в том, чтобы начав с любой альтернативы, приближаться к х* по некоторой траектории в пространстве.

С учетом того факта, что одним из ключевых показателей любой системы является ее производительность, а уже затем идут такие характеристики, как доступность, надежность, безопасность и т.п., поэтому на одной из осей необходимо отразить производительность системы. Единицы измерения производительности зависят от рабочей нагрузки, под которой понимаются не только не приложения, но и операционная система и промежуточное программное обеспечение. Например, для SAP единицей измерения производительности будет SAPS. В случае вертикального масштабирования по другой оси должно откладываться количество ресурсов в системе (количество процессоров, планок памяти), для горизонтального – количество узлов (серверов или систем хранения данных). На данном этапе получается лишь зависимость производительности системы от числа ее компонент, поэтому возникает вопрос о влиянии смены поколений ресурсов, периоде поддержки аппаратной части программной. Для этого необходимо ввести третью ось, где будет отсчитываться время. Именно по данной оси будут ограничиваться области, связанные, например, со временем лицензирования программного обеспечения на определенном типе процессоров. Предполагается, что подавляющее большинство факторов, влияющих на масштабируемость, можно выразить через соотношения, основанные на трех позициях – производительности, количества элементов в системе и времени.Итого при решении следующих задач можно ограничить область, где будет находиться решение, проведя следующие действия:

1. Выразить формулой зависимость производительности системы от числа элементов
2. Оценить периодичность выпуска и нового поколения ресурсов и временные рамки целесообразности перехода.
3. Оценить периодичность выпуска новых версий программного обеспечения и очертить рамки поддержки им аппаратного обеспечения.

Выводы

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

Список литературы

1.     Дубов Ю.А., Травкин С.И., Якимец В.Н. Многокритериальные модели формирования и выбора вариантов систем. – М.: Наука, 1986 – 296 с.

2.     Спиряев О. Вертикальное и горизонтальное масштабирование систем // BYTE. 2004. №3 (67).

Проблемы, возникающие при масштабировании инфраструктуры.

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

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

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

• ·        Улучшение сервиса
• ·        Сокращение расходов
• ·        Управление рисками

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

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

Можно привести более простой пример: предполагается, что фирма закупает определенное число единиц оборудования, которое способно обеспечивать определенный уровень производительности, достаточный для удовлетворения требуемых уровней сервиса. Руководство заказчика оценивает, что через год клиентская база увеличится на 30%, что ведет за собой большую нагрузку на систему. Очевидно, что абсолютно не рационально покупать новые сервера и системы хранения данных (СХД) для удовлетворения новых потребностей, что снова приводит к вопросу масштабирования существующей инфраструктуры, поэтому нужен быстрый механизм по выделению ресурсов.

Здесь необходимо отметить два вида масштабируемости: вертикальное (scale-up) и горизонтальное (scale-out)[2]. Возможны случаи по использованию данных типов как раздельно, так и совокупно в одном решении. Под вертикальным масштабированием подразумевается увеличение ресурсов в рамках одного сервера, т.е. это может быть вставка в свободные слоты дополнительной памяти, добавление процессоров и т.п. Под горизонтальным масштабированием понимается увеличение количества серверов, соединенных в один вычислительный узел, другими словами, фактически это кластер, причем в данном случае не важно, какого он типа: Active/Active илиActive/Passive.

Проблемы при вертикальном масштабировании

С каждым годом появляется все больше и больше различных моделей процессоров, которые более производительны и потребляют меньше энергии. В связи с этим возникает вопрос: какое именно поколение использовать? Более того, проблема стоит не столь остро, когда строится новая инфраструктура, где основным сдерживающим фактором является цена. В случае же с модернизацией инфраструктуры отправной точкой является именно существующая инфраструктура и ее составляющие. Предположим, что компания уже имеет сервер Power595 с 32 процессорами Power6, имея еще 32 слота свободными и доступными для заполнения, но в этот момент на рынке появляются новое семейство процессоров Power7, которые превосходит предшественника по всем параметрам. Заказчик рассчитал, что для поддержки его новых задач производительности 32 процессоров поколения Power6 вполне достаточно, но возникает вопрос: что делать при дальнейшем росте потребностей бизнеса и необходимости в выделении большего количества вычислительных мощностей? Что более целесообразно: дозаполнить существующий сервер, который несет большие операционные расходы, или затратить средства на новый, более производительный сервер с меньшими операционными расходами? Здесь существенное влияние оказывает также вероятность как прогнозируемых, так и непрогнозируемых пиковых нагрузок на систему, и в случае непредвиденных ситуаций необходимо иметь запас для увеличения производительности.

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

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

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

Проблемы при горизонтальном масштабировании

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

На выборе правильной нагрузки для распараллеливания стоит остановиться более подробно.Важно различать следующие типы кластеров: Active/Passive  иActive/Active. Для вертикального масштабирования данное разделение было не столь существенно, так как изменялись компоненты серверов, а не их количество, в случае горизонтального масштабирования данный вопрос, напротив, очень важен. В случае Active/Passive только один узел является активным и обрабатывает задачи, а другие узлы находятся в «горячем» резерве, способные продолжить функционирование системы при отказе основного узла. Для Active/Active кластера характерно распараллеливание задач, т.е. параллельная обработка на всех узлах кластера, что, безусловно, повышает эффективность выполнения системы, но в то же время и усложняет ее. Первый тип кластера встречается намного чаще из-за легкостипри установке и способности обработки практически любой задачи, второй тип более сложен, но более эффективно использует имеющиеся ресурсы и исключает простой второго сервера. Примером Active/Passive кластераможетслужить Microsoft Cluster Services илиVeritas Cluster Server, Oracle Real Application Cluster или DB2 PureScale – примеры Active/Active кластера. При рассмотрении вопросов масштабируемости наибольший интерес представляет именно Active/Active кластер, способный производить одновременную обработку на нескольких узлах, что позволяет увеличивать или уменьшать число элементов, изменяя производительность системы. Для Active/Passive кластера число элементов не оказывает влияние на производительность решения, а больше влияет на отказоустойчивость, создавая дополнительные узлы для резервирования.

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

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

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

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

Влияние температуры в ЦОД на надежность оборудования

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

Также важно отметить, что уже при температуре 27С надежность оборудования становится меньше примерно в 1,3 раза или на 30%, из чего можно сделать важный вывод: покупка дорогостоящего оборудования с высокими показателями надежности (MTBF) при неправильном размещении будет отнюдь не лучше, чем покупка менее дорогого оборудования, но расположенного в комфортных условиях. 

Температура[1]	Среднее значение коэффициента отказа	Минимальное значение коэффициента отказа	Максимальное значение коэффициента отказа
15	0,72	0,72	0,72
17,5	0,87	0,8	0,95
20	1	0,88	1,14
22,5	1,13	0,96	1,31
25	1,24	1,04	1,43
27,5	1,34	1,12	1,54
30	1,42	1,19	1,63
32,5	1,48	1,27	1,69
35	1,55	1,35	1,74
37,5	1,61	1,43	1,78
40	1,66	1,51	1,81
42,5	1,71	1,59	1,83
45	1,76	1,67	1,84

---

[1] http://tc99.ashraetcs.org/documents/ASHRAE%20Whitepaper%20-%202011%20Thermal%20Guidelines%20for%20Data%20Processing%20Environments.pdf

Данные в таблице являются открытыми и представлены независимой ассоциацией ASHRAE (American Society of Heating, Refrigerating and Air Conditioning Engineers)

На графике более наглядно отражена тенденция к увеличению количества отказов и, как следствие, уменьшению MTBF с ростом температуры. Можно считать, что при температуре в 45 надежность системы оказывается в 2 раза меньше, чем она заявлена согласно паспортным характеристикам, что вносит коррективы в расчет надежности системы в целом.

В итоге представленные показатели можно использовать в следующих подходах:

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