Инновации рядом: Эластичное ПО расширяет границы

Новые концепции и стратегии требуют обновления лексикона. По мере движения в направлении менее дорогих, в высшей степени гибких и дружественных к облаку архитектур для корпоративных ИТ-решений была выработана концепция эластичности. В этой статье исследуется конкретное определение эластичности путем описания примеров из IBM® WebSphere® eXtreme Scale — эластичной grid-системы, размещаемой в оперативной памяти. Из журнала IBM WebSphere Developer Technical Journal.

Роберт Вишневски, технический пропагандист, IBM

Роберт Вишневски— инженер-программист, специализируется в вопросах производительности и масштабируемости. Он в течение 7 лет занимался вопросами производительности продукта WebSphere Applications Server, уделяя внимание всем аспектам продукта — от EJB/JPA до автономных вычислений и разработки эталонных тестов. В настоящее время, будучи техническим пропагандистом, Роберт использует свой опыт для рассмотрения пользовательских сценариев и применения стратегий XTP в реальном мире.



09.10.2012

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

Развить навыки по этой теме

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри Облачные вычисления: общие сведения о концепции «Инфраструктура как сервис»

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

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

Эластичность в системе или компоненте системы (в качестве примера я буду использовать программное обеспечение, поскольку ежедневно работаю с продуктом IBM WebSphere eXtreme Scale) подразумевает наличие трех конкретных степеней свободы:

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

Масштабирование без видимых ограничений

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

При реализации концепции эластичности в продукте WebSphere eXtreme Scale мы учитывали влияние исключительно больших grid-систем на каждый аспект продукта. Несколько примеров, которые прекрасно это иллюстрируют:

  • Во-первых, сама архитектура инфраструктуры членства в grid-системе подразумевает разделение на меньшие, решаемые и ограниченные задачи масштабирования. Вместо того чтобы контролировать тысячи серверов в единой основной группе, служба каталогов (административный процесс, который осуществляет обработку структуры grid-системы) разделяет участников на группы по 20. В каждой из этих отдельных групп выполняется алгоритм представления членства, включающий отправку сигналов подтверждения работоспособности, который надежно регистрирует данные и разделяет свои функции с IBM WebSphere Application Server. Выбранный «руководитель» этой меньшей группы обеспечивает передачу актуальной информации о статусе группы в службу каталогов, которой затем требуется поддерживать связь только с 1/20 частью от общего количества членов grid-системы.
  • Еще одним примером является взаимодействие клиентов с самой grid-системой. Часто возникает вопрос о возможном «узком месте», связанном с использованием единого административного процесса, такого как служба каталогов. Службы каталогов также могут дублироваться и объединяться в кластеры, но это делается исключительно для целей резервирования. Дело в том, что одна служба каталогов в действительности способна удовлетворять потребности практически неограниченного количества клиентов, поскольку эти клиенты взаимодействуют со службой каталогов только один раз для подключения к grid-системе. В процессе такого взаимодействия служба каталогов возвращает информацию о grid-системе, включая полную карту маршрутизации, определяющую местоположение всех разделов grid-системы и соответствующего пространства ключей для каждого из них. После этого клиенты взаимодействуют непосредственно с разделами и даже обновляют данную таблицу маршрутизации посредством взаимодействия по подканалам во время обычного процесса выполнения транзакций. В такой ситуации служба каталогов может сосредоточить свое внимание на управлении балансом и членством в grid-системе по мере добавления и удаления ресурсов.

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

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

Отказоустойчивость и самовосстановление

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

Продолжим рассмотрение нашего примера с grid-системой WebSphere eXtreme Scale. По мере расширения до grid-систем из сотен или тысяч процессов-контейнеров вероятность потери или необходимости технического обслуживания одного из этих процессов становится все выше. Устойчивость к таким событиям может быть обеспечена путем репликации, которая является одной из ключевых компетенций продукта WebSphere eXtreme Scale и других аналогичных предложений в области grid-систем, размещаемых в оперативной памяти. Кроме того, поскольку размещение и миграция данных осуществляются совершенно прозрачно за «черным ящиком» интерфейсов API клиента WebSphere eXtreme Scale, автоматически создается новая точная копия для установления отказоустойчивости.

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

Простота администрирования

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

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

В случае с продуктом WebSphere eXtreme Scale подход достаточно прост. Информация о конфигурации сосредоточена на структуре и характеристиках самой grid-системы, а не на каких-либо сведениях о конкретных участвующих процессах. Например, вы указываете, на сколько разделов требуется разбить данные и как должна осуществляться репликация этих разделов. Получив эту информацию, продукт WebSphere eXtreme Scale «примеряет» ее на доступных участников grid-системы и обеспечивает соблюдение политик, установленных в конфигурации. При запуске каждому участнику grid-системы предоставляется один и тот же набор параметров конфигурации, а сведения о местонахождении данного участника в grid-системе контролируются и определяются автоматически.

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

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


В защиту модных слов

Можно с уверенностью утверждать, что даже самые распространенные основополагающие технологии в области вычислений начали свой путь с тех или иных модных слов. Нужно просто стремиться к тому, чтобы при добавлении в лексикон новых концепций и целевых установок наполнять их смыслом и полезными целями. При таком подходе становится понятно, что эластичность в корпоративных решениях может стать ценной концепцией, если она четко определена и продумана вплоть до логических заключений. Говоря о продукте WebSphere eXtreme Scale как об эластичной grid-системе, мы все время пытаемся придать этому конкретный и полезный смысл, и мы будем продолжать в этом же духе при применении подобных концепций к другим решениям, разрабатываемым для создания по-настоящему гибких инфраструктур..

Ресурсы

Научиться

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=839637
ArticleTitle=Инновации рядом: Эластичное ПО расширяет границы
publish-date=10092012