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

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

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

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

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

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

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

Можно привести более простой пример: предполагается, что фирма закупает определенное число единиц оборудования, которое способно обеспечивать определенный уровень производительности, достаточный для удовлетворения требуемых уровней сервиса. Руководство заказчика оценивает, что через год клиентская база увеличится на 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 кластере каждый сервер может иметь свою собственную базу данных, поэтому необходим гибкий механизм резервирования данных в целях исключения потери информации.

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