IBM WebSphere eXtreme Scale

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 23:02, 17 июня 2017.
(перенаправлено с «WebSphere eXtreme Scale»)
IBM WebSphere eXtreme Scale
Разработчики: IBM
Выпущена: 8.6
Операционная система: AIX, HP-UX, Linux, Linux on System z, Solaris, Windows, z/OS, z/OS.e
Платформа: Java
Локализация: Языков доступно: 1
Тип ПО: grid-система управления данными
Лицензия: Shareware
Веб-сайт Главная страница Триал-версия

IBM WebSphere eXtreme Scale — это гибкая масштабируемая grid-система управления данными в памяти. Данная система предназначена справляться с резко увеличившимся в последнее время количеством транзакций. Данное программное обеспечение предоставляет собой расширенное качество услуг в высокопроизводительных вычислительных средах.

Краткий обзор

Что такое WebSphere eXtreme Scale?

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

Например, организация, использующая WebSphere eXtreme Scale, улучшила время доступа к ключевым данным с 60 мс до 6 мс при 450000 активных пользователей и 80000 запросах в секунду. Данная система позволила снять ограничения, поставленные из-за достижения максимума производительности базы данных. Технология WebSphere eXtreme Scale позволила уменьшить нагрузку в 10 раз, расширив количество активных пользователей до пяти миллионов и количество запросов до одного миллиона в секунду.

Принципы экстремальной масштабируемости

Идея WebSphere eXtreme Scale основывается на следующих фундаментальных принципах:

  • Помещение данных в память
  • Линейное горизонтальное масштабирование
  • Кэширование

Помещение данных в память

Структура памяти

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

Учитывая, что большинство данных находится на медленных дисках, как можно сделать так, чтобы приложения, в конечном счёте, не ожидали получения информации от них? Ответ прост – необходимо поместить как можно больше данных в компьютерную память, чтобы устранить дорогостоящие операции чтения/записи. Чем быстрее доступ к данным, тем быстрее работает приложения. Соответственно уменьшается время отклика и увеличивается производительность и пропускная способность. Однако это не получило широкого применения по двум причинам:

  • Как правило, данные, хранящиеся на диске, являются очень важными (например, банковские счета). Они должны быть стойкими и защищёнными от случайных потерь. Проблема оперативной памяти заключается в том, что при отключении питания или перезагрузке компьютера данные в ней будут утеряны. У дисковых хранилищ такой проблемы нет.
  • Вероятно, все данные не впишутся в оперативную память. 32-битная JVM имеет около 2 Гбайт используемой памяти. Это достаточно значительное количество данных, но связующее программное обеспечение должно делить это пространство с логикой приложения.

Можно разместить данные на другой машине. Чтобы получить данные по быстрой сети от другой машины, потребуется около 2 миллисекунд, в то время как от локального диска данные можно получить за 20-40 миллисекунд. Использование памяти других машин является хорошим решением возникших проблем. Машинная память используется операционной системой, связующим программным обеспечением, логикой приложения. Помимо всего этого туда помещаются данные. Использование удалённых машин даёт гораздо больше памяти для данных, которые можно получить гораздо быстрее, чем с диска. Это также повышает их доступность: можно хранить копии данных на других машинах, если первая выйдет из строя.

Разбиение данных для линейного горизонтального масштабирования

Производительность при различных подходах к масштабированию

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

Возможности масштабирования в обычном трёхуровневом приложении

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

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

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

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

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

В исходном примере, описанным выше, данными ключа являлись профили пользователей, которые могут быть распределены по множеству машин для параллельной обработки. Для того, чтобы добиться десятикратного уменьшения времени отклика, использовалось десять серверов. WebSphere eXtreme Scale позволяет масштабировать до тысяч машин, что поддерживает до 500 миллионов пользователей с одинаковым временем отклика в 6 мс. Только распределение данных в памяти позволило уменьшить время отклика в 10 раз и увеличить в тысячи раз количество пользователей. Это и есть линейное масштабирование.

Кэширование

Сторонний кэш

Ключевой особенностью WebSphere eXtreme Scale является обеспечение большого, масштабируемого и гибкого кэша.Кэш-память представляет собой часть памяти, которая используется для хранения данных. Первым местом для поиска данных является кэш. Если данные там, то произошло удачное обращение к кэш-памяти (cache hit) и вы получите необходимую информацию за десятки наносекунд. Если нужных данных там нет, то произошло неудачное обращение к кэш-памяти (cache miss) и компьютеру придётся искать данные на диске за десятки миллисекунд, что в миллион раз медленнее. После того, как вы получаете данные с диска, вы помещаете их в кэш, а затем возвращаете.

Эффективность кэша прямо пропорциональна коэффициенту нахождения данных в кэш-памяти (hit ratio), который является процентным отношением удовлетворённых запросов к кэшу к общему количеству запросов. Если все данные помещаются в кэш-памяти, то данные только один раз считываются с диска; после этого все запросы удовлетворяются со скоростью кэш-памяти. Есть два основных преимущества использования кэш-памяти:

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

В большинстве случаев кэш находится в том же адресном пространстве, в котором используются эти данные. Такое расположение обеспечивает максимальную скорость передачи данных, но ограничивает размер кэша. WebSphere eXtreme Scale может использовать другие виртуальные Java-машины (JVM) для кэширования. Такие машины могут выделять кэш так, что большая часть памяти виртуальной машины Java используется и доступна для данных приложений, без совместного использования с связующим программным обеспечением, инфраструктурой или программным кодом. Эти виртуальные машины могут быть на той же машине. Локальные JVM обеспечивают быстрый доступ к памяти, но в конечном счёте, физические циклы памяти и процессора должны использоваться совместно с операционной системой, другими приложениями и JVM на машине. Поэтому, чтобы получить большие кэши, а также сбалансированную и распараллеливаемую загрузку доступа, необходимо использовать JVM на других удалённых компьютерах для получения доступа к большему количеству физической памяти. Эта физическая память является ключом к ускорению доступа. Удалённые JVM обеспечивают гораздо больший кэш, который является более масштабируемым.
Рассмотрим ситуацию, когда данные в кэше изменяются. Запись может усложнить ситуацию с кэшем. Кэширование работает лучше всего, когда данные в кэше не меняются (то есть, нет записи в кэш и поэтому отношение записи к чтению равно нулю) или меняются редко (например, если кэшировались профили пользователей, то они меняются нечасто и поэтому отношение записи к чтению мало). Есть два важных случая использования записи:

  • Процесс использует кэш и изменяет данные.
  • Процесс не использует кэш и изменяет данные.
Кэширование при использовании масштабирования

В первом случае, есть два варианта:

  • В кэше сквозной записи данные записываются в кэш-память и на диск, перед тем как возвратиться к процессу записи. В этом случае запись происходит на скорости диска, что плохо. Хорошо то, что данные на диске соответствуют данным в кэше.
  • В кэше отложенной записи, как только данные находятся в кэше, то запрос возвращается, и обработка продолжается. В этом случае процесс записи продолжается со скоростью памяти, а не со скоростью диска. Но теперь данные на диске с течением времени становятся неактуальными. Если новая копия кэша не запишется на диск перед выключением компьютера или выходом из строя кэш-памяти, то обновление теряется, и это очень негативный фактор. Тем не менее, WebSphere eXtreme Scale может держать дополнительные копии кэша на других машинах, чтобы обеспечить надёжное кэширование отложенной записи. Таким образом, кэш отложенной записи даёт вам скорость памяти для доступа к данным на всех операциях записи, а также для всех удачных обращений к кэшу.

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

  • Сделать тайм-аут записей в кэш. Например, каждая запись автоматически удаляется из кэша после некоторого заданного пользователем интервала, скажем 10 минут. Это вынуждает кэш перезагружаться с диска, и, таким образом, кэш будет оставаться неактуальным не более 10 минут.
  • Обнаружить изменения в исходных данных, а затем либо вытеснить изменённые данные из кэша (который по требованию будет перезагружен), либо перезагрузить обновлённые данные в кэш.

WebSphere eXtreme Scale поддерживает оба этих подхода.

Подробности реализации

WebSphere eXtreme Scale является неинвазивным промежуточным программным обеспечением. Оно упаковано в цельный JAR-файл размером 15 Мбайт, не имеет зависимости от WebSphere Application Server, совместимо с текущими и предыдущими версиями WebSphere Application Server Network Deployment, WebSphere Application Server Community Edition, а также с некоторыми приложениями, разработанными другимими компаниями, такими как JBoss и WebLogic. WebSphere eXtreme Scale также работает с J2SE, Sun, IBM JVM и Spring. Из-за этого один кэш или грид кэшей может охватывать несколько ячеек WebSphere Application Server, в случае необходимости. Если вы не хотите управлять виртуальными машинами и приложениями через командную строку, вы можете установить внешнюю оболочку. WebSphere eXtreme Scale может управляться и контролироваться через IBM Tivoli Monitoring, а также через Hyperic HQ и Wily Introscope. WebSphere eXtreme Scale использует только протокол TCP для обмена данными. Никаких специальных сетевых топологий или аналогичных компонентов не требуется. Географически удалённые узлы могут быть использованы для создания точных копий кэша.

Разделы

WebSphere eXtreme Scale использует концепцию разделения для горизонтального масштабирования кэша. Данные хранится в кэше. Каждый элемент данных имеет собственный уникальный ключ. Данные помещаются и извлекаются из кэша на основе их ключей. Для пояснения рассмотрим простой пример хранения почты в картотеке, где ключом является фамилия адресата. В кабинете есть два ящика, один с маркировкой А-Л, другой М-Я, в которые вы раскладываете почту. Каждый ящик является сегментом (разделом). Вы можете масштабировать «кэш» почты, добавив ещё два шкафа. Вы повторно маркируете ящики: А-Ж, З-П, Р-Ц, Ч-Я, а затем ещё раз раскладываете почту по ящикам. Вы удвоили размер своего почтового «кэша», и вы можете продолжать расширение. Одной из проблем данного подхода является то, что фамилии людей распределяются неравномерно. Ящики М, Л, П заполнятся быстрее ящиков с фамилиями на Ф, Х, Щ. Это приведёт к неравномерной нагрузки на кэш с точки зрения памяти и обработки. Способ разбиения (сегментации) заключается в вычислении хэша ключа. Хэш-код представляет собой целое число, представляющее уникальный номер каждого ключа. (Например, если ключ является целым числом, это значение может служить в качестве хэш-кода.) В WebSphere eXtreme Scale пользователь сам выбирает количество разделов кэша. Чтобы поместить элемент в кэш, программа вычисляет хэш ключа, делит его нацело на количество разделов. Получившийся остаток определяет раздел хранения элемента. Например, если у вас есть три раздела, хэш-код ключа равен 7, тогда номер раздела, где содержится искомый элемент, равен 7 (mod 3) = 1. Разделы нумеруются с нуля. Хеш должен обеспечивать равномерное распределение значений по ключевому пространству таким образом, чтобы разделы были сбалансированы. WebSphere eXtreme Scale вычисляет хэш автоматически. Если необходимо можно указать хэш-код самостоятельно.

В примере «кэша» почты, описанном выше, каждый ящик являлся разделом, которых в картотеке было два. Они имеют фиксированный размер. Если применить эту аналогию к WebSphere eXtreme Scale, картотекой является контейнерный сервер, который работает в JVM. Это означает, что сервер может содержать, в лучшем случае, 2 Гб данных (или больше, если используются 64-битные виртуальные машины). В WebSphere WebSphere eXtreme Scale контейнерный сервер может содержать переменное количество разделов. Таким образом, раздел может содержать не более 2 Гб элементов. Предположим, вы используете большое количество разделов, например, 101. Это означает, что ваш кэш может хранить до 202 Гб (101 раздел * 2 Гб) информации. Контейнерные серверы могут быть распределены по нескольким удалённым компьютерам, а некоторые могут совместно использовать одну ту же машину. В приведённом случае с одним контейнерным сервером, у пользователя будет весь 101 раздел на одном сервере, и поэтому он может иметь только 2 ГБ элементов. Для увеличения необходимо просто запустить другой сервер, желательно на другой машине, чтобы распределить нагрузку. Имея ещё один доступный сервер, WebSphere eXtreme Scale автоматически распределяет нагрузку кэша между двумя контейнерными серверами, таким образом, что 50 из 101 разделов будет перенесено на второй сервер. Если вы добавили третий сервер на третью машину, то нагрузка будет распределена путём перемещения 17 разделов с первого сервера и 16 разделов со второго сервера на новый контейнерный сервер. Новый сервер будет иметь 33 раздела, а первые два – по 34 каждый. Таким образом, WebSphere eXtreme Scale обеспечивает линейное масштабирование. С 101 разделом и одним сервером, у пользователя будет до 2 Гб свободного места для хранения данных. С 101 разделом, вы можете масштабировать до 101 контейнерного сервера с объёмом 202 Гб. Эти контейнерные серверы должны быть распределены на несколько машин. Идея заключается в том, что нагрузка равномерно распределяется по разделам, а WebSphere eXtreme Scale равномерно их распределяет по доступным машинам. Таким образом, вы получаете динамический и гибкий кэш линейного масштабирования.

Резервное копирование

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

  • Раздел – это логическое понятие. Он представляет собой 1/N данных в кэше, где кэш разбивается на N частей или разделов.
  • Копия – это реальная, физическая часть памяти, которая хранит содержимое раздела.
Пример разбиения, показывающий размещение шардов

Для обеспечения отказоустойчивости и высокой доступности, алгоритмы распределения копий гарантируют, что первичные и остальные копии никогда не находятся в том же контейнере. Копии могут быть синхронными или асинхронными; различие важно, когда данные записываются в кэш. Операция записи не завершится, пока все синхронные копии не подтвердили получение новых данных. Асинхронные копии обновляются после того, как завершиться операция. Таким образом, они обеспечивают более высокую производительность операций (как правило, в шесть раз быстрее), но увеличивает риск потери данных в случае отказа. Выбор количества синхронных и асинхронных копий основывается на требованиях к производительности и доступности приложения. Например, вы можете иметь синхронную копию на другой машине в том же самом центре обработки данных, а также асинхронную копию на той же машине, но в другом центре обработки данных. В WebSphere eXtreme Scale зоны используются для определения понятия центров обработки данных, и программа автоматически их определяет. При выборе количества синхронных и асинхронных копий, а также их размещение по зонам, можно балансировать между производительностью, доступностью и устойчивостью перед угрозами сбоев.

API

Есть много вариантов API, которые использует код приложения для доступа к данным. Они обычно хранятся в базе данных. В WebSphere eXtreme Scale используется JDBC (Java Database Connectivity — соединение с базами данных на Java). Существует также новый стандарт JPA (Java Persistence API). Это спецификация для сохранения объектов Java в хранилище реляционных данных, обычно баз данных. Многие пользователи имеют свои собственные уровни доступа к данным со своими API, к которому привязывается бизнес-логика. Уровень доступа можно использовать для получения данных JDBC или JPA. Таким образом, эти основные вызовы доступа к данным объединяются в слое доступа к данным и скрываются от бизнес-логики.
Существуют два использования API: интерфейсы для получения данных с диска и различные интерфейсы для получения данных из кэша. Таким образом, необходимо изменить код приложения для использования кэша, как было описано ранее. На запрос чтения, прежде всего, нужно проверить кэш. В случае ошибки получите данные с диска, а затем положите их в кэш. Приложение должно запрограммировать эту логику с использованием дискового интерфейса и кэша. Если используется уровень доступа к данным, код может быть скрыт от используемого приложения. Как правило, приложения запускаются с интерфейсом на диск и должны быть преобразованы интерфейс линейного кэша. Если используется уровень доступа к данным, код может быть скрыт от использования приложением.
WebSphere eXtreme Scale предлагает три API для доступа к данным:

  • ObjectMap API является низкоуровневым, высокопроизводительным API. Это похоже на Java HashMap, с простыми операциями создания, чтения, обновления и удаления.
  • EntityManager API является высокоуровневым простым в использовании интерфейсом. Он очень похож на интерфейс JPA. Если ваш код использует интерфейс JPA, использование EntityManager API упрощает перекодирование.
  • The REST data service enables HTTP and Microsoft .NET clients using the ADO.NET Data Services Protocol to access WebSphere eXtreme Scale data grids. Служба данных REST позволяет клиентам HTTP и Microsoft.NET использование ADO.NET Data Services Protocol для доступа к grid-системе WebSphere eXtreme Scale.

С точки зрения API существует три общих способа использования WebSphere eXtreme Scale:

  • Не требуется изменения кода, только изменение конфигурации. В этих случаях WebSphere eXtreme Scale предоставляет подключаемые модули для существующей инфраструктуры, которую приложения уже используют, для расширения возможности инфраструктуры кэширования, в том числе и WebSphere eXtreme Scale. Праграмма используется в качестве стороннего кэша.
  • Используйте WebSphere eXtreme Scale качестве стороннего кэша. В этом случае вы можете вставить небольшое количество кода в нескольких ключевых областях и использовать API ObjectMap для кэширования данных.
  • Значительное улучшение масштабирования происходит за счёт изменения интерфейса данных приложения для WebSphere eXtreme Scale, таким образом, что она становится системой записи. В этом случае WebSphere eXtreme Scale является линейным кэшем. Если вы используете JPA, вы можете использовать WebSphere eXtreme Scale EntityManager API, чтобы сделать преобразование проще.

Сторонний кэш использует принципы кэширования и data-in-memory, в то время как линейный кэш позволяет эффективно использовать принципы разбиения и горизонтального масштабирования. WebSphere eXtreme Scale предлагает Data Grid API в качестве дополнительного средства для успешного использования разбиения. Идея заключается в том, чтобы переместить обработку данных, не помещая данные в процессор. Бизнес-логика может работать параллельно над всеми или только над некоторыми разделами данных. Результаты параллельной обработки могут быть объединены в одном месте. Помимо распределения хранения и восстановления данных через грид, обработка этих данных также может быть распределена по серверам разделов грида для обеспечения линейного масштабирования.

Примеры использования WebSphere eXtreme Scale

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

Улучшение службы динамического кэша WebSphere Application Server

Служба динамического кэша WebSphere Application Server (часто упоминается как Dynacache) является отличным примером использования стороннего кэша для повышения производительности. Dynacache это функция WebSphere Application Server, которая возникла при разработке IBM веб-сайта Олимпийских игр 1998 года. Чтобы обеспечить экстремальное масштабирование для мировой аудитории, идея состояла в том, чтобы кэшировать данные web-страниц в памяти после того, как та была создана: это похоже на шаблон data-in-memory. Кэш запоминает не только процесс ввода/вывода с диска, но и время обработки этих данных. Есть несколько способов для отслеживания большого динамического кэша. Некоторые из них могут вырасти до 30 или 40 Гб. Это превышает виртуальную ёмкость памяти процесса, таким образом, большая часть данных находится на диске, который является дорогим для доступа. Кроме того, эти кэши находятся на каждой машине. Динамический кэш также является частью адресного пространства приложения. WebSphere eXtreme Scale предоставляет простой в использовании плагин для замены динамического кэша и дисковой системы распределенным динамическим гридом в памяти. Необходимо просто указать параметры конфигурации в файле XML, без использования программирования. Преимущества данного метода:

  • Кэш удаляется из адресного пространства приложения и помещается в адресное пространство контейнера WebSphere eXtreme Scale.
  • Кэш может легко масштабироваться до 40 Гб, который может быть распределён по нескольким машинам таким образом, что весь кэш может находиться в памяти с минимальным временем доступа к нему.
  • Кэш может совместно использоваться всеми приложениями и экземплярами WebSphere Application Server, которые нуждаются в нём.

Кэш второго уровня для Hibernate и OpenJPA

WebSphere eXtreme Scale включает в себя плагины для кэша 2-го уровня (L2) для поставщиков OpenJPA и Hibernate JPA. JPA позволяет настроить сторонний кэш для повышения производительности. Поскольку диски являются медленными, быстрее получить данные из кэша 2-го уровня, чем с диска. WebSphere eXtreme Scale может обеспечить очень большие кэши. Большие распределенные WebS WebSphere eXtreme Scale кэши могут также использоваться несколькими OpenJPA или Hibernate экземплярами процесса. Полезной особенностью кэша JPA является то, что для использования никаких изменений в коде не требуется, просто необходимо иметь некоторые свойства конфигурации (например, размер и тип объекта в кэше) в файле persistence.xml.

Копирование сеанса HTTP

Данные сеанса HTTP является идеальным для использования WebSphere eXtreme Scale. Вы можете значительно увеличить производительность путём перемещения данных с диска в память, посредством данных, находящихся в памяти. Данные хранятся на диске (или в базе данных) в первую очередь для обеспечения доступности в случае выхода из строя, разрешая другому веб-серверу получить доступ к данным сеанса, если первый сервер вышел из строя.
WebSphere eXtreme Scale обеспечивает отказоустойчивость и доступность данных в случае сбоя, и он обрабатывает и масштабирует гораздо лучше дисков, поэтому является идеальным решением для этих данных. WebSphere eXtreme Scale очень прост в использовании. Никакого изменения кода приложения не требуется. Просто поместите файл XML в каталог META-INF веб-приложения, чтобы настроить его так, чтобы WebSphere eXtreme Scale сохранил данные HTTP-сессии. В случае выхода из строя, доступ к данным сеанса будет быстрее, так как они находится в памяти.

Кэш-посредник SOA ESB

У банка с 22 миллионами интернет-пользователей существуют профили клиентов, хранящиеся в CICS Enterprise Information (EIS) на хосте System z. Некоторые приложения могут получить доступ к этим профилям. Здесь хост – это большой компьютер, где хранятся профили в виде базы данных. Для получения данных профилей каждое приложение использует сервис-ориентированную архитектуру (SOA) поверх сервисной шины предприятия (ESB). Каждое приложение имеет свой собственный кэш профиля, но они есть в адресном пространстве каждого приложения. Кэш уменьшает некоторые нагрузки на вызов профилей от хоста EIS, а большой общий кэш позволит сократить большую нагрузку.

WebSphere eXtreme Scale используется в качестве подключённого к сети стороннего кэша, содержащего около 8 Гбайт (4 Гбайт + 4 Гбайт копий для высокой доступности). Посредничество вставляется в ESB запоминать профиль выборки вызовов службы для запоминания выборки профиля. Имя службы и параметры используются в качестве ключа, и значением является сам профиль. Если профиль не находится в кэше, то посредник получает его от хоста и сохраняет результат в кэш. Из кэша удаляются записи старше 30 минут, чтобы предотвратить неактуальность информации и ограничение размера кэша. Никаких изменений кода приложения не требуется; посредник вставляется прямо в ESB.

До использования WebSphere eXtreme Scale вход занимал 700 мс с двумя серверными вызовами. Использование WebSphere eXtreme Scale позволило уменьшить время авторизации до 20 мс с доступом к кэш-профилю, который в 35 раз быстрее. Кроме того, нагрузка на EIS была снижена. Ежемесячные расходы значительно уменьшились в результате этого снижения нагрузки. SOA ESB обеспечивает простую в использовании точку вызова, посредник, используя последовательный кэш, может быть легко вставлен без изменения приложений.

Обслуживание профилей клиентов

Вернёмся к примеру, где база данных достигла своего предела. В этом случае у пользователя пиковая скорость равна 8000 просмотров страниц в секунду. Приложение использует базу данных SQL для выполнения запросов и обновления профилей. Каждая страница приложения производит 10 операций поиска профилей в базе данных по 60 мс на каждый, при пиковой нагрузке выполняя 80000 запросов в секунду. Каждый профиль пользователя весит 10 Кбайт. При 10 миллионах зарегистрированных пользователей их профили занимают 100 Гбайт памяти. Если база данных выходит из строя или если имеются проблемы доступа к глобальной сети по всему земному шару, приложение зависает. Хранение данных в памяти решает эти проблемы.

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

Как уже говорилось ранее, используя отложенную запись, транзакция завершается, когда данные записываются в кэш-память, которая является быстрой. Данные записываются на диск позже. Это означает, что кэш отложенной записи должен надёжно хранить данные в кэше, пока они не запишутся на диск. WebSphere eXtreme Scale обеспечивает эту надёжность за счёт точных копий. Вы можете настроить эту задержку записи с точки зрения количества операций записи или количества времени. Если серверная база данных выходит из строя или сетевое подключение к нему выходит из строя или замедляется, ваше приложение продолжает работать, и данный сбой никак не повлияет на приложение. WebSphere eXtreme Scale кэширует все изменения и применяет их, когда восстанавливается база данных, или применяет их к резервной копии базы данных, если он переводится в состояние онлайн.

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

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

WebSphere eXtreme Scale хранит данные, используя кэш отложенной записи, и устанавливается перед базой данных SQL. Контейнеры кэш-сервера развёрнуты на десяти 8-ядерных компьютерах, обслуживая профили пользователей и принимая изменения. Асинхронные точные копии используются для высокой производительности с хорошей доступностью. Каждый компьютер выполняет 8000 запросов в секунду, обеспечивая общую пропускную способность 80000 запросов в секунду с временем отклика 6 мс.

Данное решение должно масштабироваться до 1 миллиона запросов в секунду с тем же временем отклика – 6 мс. WebSphere eXtreme Scale сможет добиться этого с помощью линейного масштабирования путём добавления около 120 серверов. Каждый сервер обрабатывает около 110 Мбайт в секунду общего трафика (90 Мбайт для запросов, 20 Мбайт для копий). При данной вычислительной мощности требуется на каждом сервере несколько сетевых карт, которые увеличат производительность даже небольших серверов.

Ссылки

  1. WebSphere eXtreme Scale
  2. Getting Started with WebSphere eXtreme Scale, Part 1: Understanding WebSphere eXtreme Scale and how it works
  3. User's Guide to WebSphere eXtreme Scale