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

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

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

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

Горизонтальное и вертикальное масштабирование

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

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

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

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

Добавление большего объема памяти для кеширования может повысить производительность для большинства приложений, но это также часто обеспечивает лишь незначительное улучшение с помощью «I/O blender», созданного на виртуализированных серверах. Тем не менее, с его терабайтами емкости флэш-кеш может справиться с проблемой микширования ввода-вывода, в том числе для приложений с интенсивной транзакцией, что делает этот вариант жизнеспособным.

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

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

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

Однако IOPS можно улучшить, используя другой носитель: флэш-память, используемая в твердотельных накопителях (SSD). Разница между производительностью жестких дисков и SSD довольно глубока. Для жестких дисков, вращающихся со скоростью 7200 или 10000 об / мин, IOPS обычно находится в диапазоне 100-200. Для SSD IOPS может увеличиться в четыре раза до более чем 1 000 000. Этот вариант без лицензии становится очевидным выбором для улучшения цены и производительности с использованием приложений баз данных с интенсивным использованием ввода-вывода.

Возможность добиться значительных улучшений в производительности привела к тому, что все большее число решений SSD и массив флэш-памяти стали доступны. Хотя сравнение всех этих различных решений выходит за рамки этой дискуссии, есть одно решение, которое заслуживает рассмотрения здесь: поддержка качества обслуживания (QoS) для обеспечения производительности в среде с несколькими арендаторами.

По словам Генри Балтазара, старшего аналитика инфраструктуры и операций в Forrester Research, «Соседи нарушают доставку облачных и корпоративных хранилищ ... Это ограничение является основной причиной того, что поставщикам облачных хранилищ сложно создавать согласованные многопользовательские среды, используя традиционные системы хранения, которым не хватает Storage QoS». Именно поэтому Балтазар называет хранилище QoS «обязательным» в облаке с несколькими арендаторами.

QoS хранилище работает почти таким же образом, как  и сетевой QoS. Лучшие решения выходят за рамки простых механизмов ограничения приоритетов, поскольку они не могут обеспечить предсказуемые и согласованные уровни эффективности при любых обстоятельствах. Единственный способ гарантировать, что критически важные для бизнеса операции всегда получат требуемую производительность, - это использовать метод Min / Max / Burst для управления IOPS:

• Min IOPS необходим, чтобы гарантировать, что каждый том получает гарантированный минимальный уровень производительности независимо от системных условий или активности приложения.
• Max IOPS необходим для установки максимального уровня производительности, который каждый том получает с течением времени в качестве средства обеспечения справедливого распределения среди всех томов.
• Burst IOPS необходим для удовлетворения случайных всплесков спроса, которые возникают практически во всех приложениях базы данных.

Масштабирование производительности с облачными сервисами

Возможность эффективного управления IOPS с использованием метода Min / Max / Burst для QoS требует некоторых базовых возможностей в массиве хранения, в том числе:

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

• Использование только SSD (для обеспечения постоянной низкой задержки)
• Настоящая масштабная архитектура (чтобы обеспечить предсказуемое повышение производительности по мере роста мощности)
• Защита данных без RAID (для обеспечения предсказуемой производительности при любом сбое)
• Сбалансированное распределение нагрузки (для устранения «горячих точек», которые могут создать непредсказуемую задержку ввода / вывода)

 Таким образом, помимо обычных критериев, используемых для оценки CSP (например, высокая доступность и аварийное восстановление, поддерживаемые соглашениями об уровне обслуживания, надежная безопасность, масштабируемость, гибкая поддержка и т. Д.), Провайдеры SaaS должны использовать CSP, который также предлагает:

• QoS хранение, которое гарантирует, что рост производительности IOPS будет предсказуемым и последовательным с течением времени при изменении конфигураций и условий

 Среда разработки / тестирования для характеристики SSD и производительности жесткого диска при различных нагрузках и обстоятельствах

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

• Поддержка гибридных архитектур, которые объединяют лучшие публичные облачные сервисы для экономичной масштабируемости, облака для обеспечения безопасности и выделенные серверы (включая кластеры базы данных)

 Заключение

 Для достижения максимальной цены и производительности необходимо, чтобы поставщики SaaS и программное обеспечение Dev / Ops уделяли одинаковое внимание как цене, так и производительности. Ценовая часть уравнения может зависеть как от лицензионных сборов, так и от выбора технологии, используемой для повышения производительности.

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

No Comments