Apache Geode

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:28, 17 января 2019.
Apache Geode
Apache Geode
Разработчики: Contributors
Постоянный выпуск: 1.7.0
Состояние разработки: Active
Написана на: Java
Операционная система: Cross-platform
Лицензия: Apache License 2.0
Веб-сайт geode.apache.org

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

Первоначально разработана GemStone Systems и на данный момент является зрелой и надежной технологией. Коммерчески доступная как GemFire™, была впервые развернута в финансовом секторе как транзакционный механизм с низкой задержкой, используемый на торговых платформах Уолл-Стрит. Сегодня эта технология используется сотнями корпоративными клиентами для высокопроизводительных бизнес-приложений, которые должны удовлетворять требованиям к низкой задержке и постоянной доступности.

Содержание

Особенности

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

Локаторы дают возможность поиска и балансировки нагрузки. Есть возможность настройки клиентов со списком локаторов служб, а локаторы, в свою очередь, поддерживают динамический список серверов-членов. По умолчанию клиенты и серверы Geode используют порт 40404 и многоадресную рассылку для обнаружения друг друга.

Apache Geode включает в себя следующие функции[2]:

  • Объединяет избыточность, репликацию и архитектуру "Shared nothing" для обеспечения безотказной надежности и производительности;
  • Горизонтальное масштабирование до тысячи членов кэша, с несколькими топологиями для удовлетворения различных потребностей предприятия. Кэш может быть распределен между несколькими компьютерами;
  • Распространение асинхронного и синхронного обновления кэша;
  • Дельта распространение распределяет только разницу между старыми и новыми версиями объекта (дельта), а не всего объекта, что приводит к значительной экономии затрат;
  • Надежные асинхронные уведомления о событиях и гарантированная доставка сообщений через оптимизированный слой с низкой задержкой;
  • Информационная осведомленность и бизнес-аналитика в режиме реального времени. Если данные изменяются по мере их получения, пользователь сразу видит изменения;
  • Интеграция с Spring Framework для ускорения и упрощения разработки масштабируемых корпоративных приложений;
  • Поддержка транзакций, совместимых с JTA;
  • Общие конфигурации кластеров, которые могут сохраняться и экспортироваться в другие кластеры;
  • Удаленное управление кластером через HTTP;
  • REST API для разработки приложений с поддержкой REST.

Высокая пропускная способность чтения и записи

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

Низкая и предсказуемая задержка

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

Высокая масштабируемость

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

Постоянная доступность

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

Уведомления о событиях

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

Параллельное поведение приложений в хранилищах данных

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

"Shared nothing". Устойчивость диска

Каждая часть кластера управляет данными на дисковых файлах независимо от других частей. Повреждения на дисках или сбои кэша у одной части не влияют на способность другого экземпляра кэша безопасно работать с файлами на диске. Архитектура «shared nothing» позволяет настраивать приложения таким образом, чтобы разные классы данных сохранялись на разных частях системы, что резко увеличивало бы общую пропускную способность приложения.

Снижение стоимости

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

Возможности одного перехода для клиента/сервера

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

Безопасность клиентов/серверов

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

Распределение данных по нескольким объектам

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

Непрерывный запрос

В системах обмена сообщениями, таких как Java Message Service, клиенты подписываются на темы. Любое сообщение, отправленное в тему, отправляется подписчику. Geode позволяет осуществлять непрерывный запрос.

Неоднородный обмен данными

Приложения C #, C ++ и Java могут совместно использовать бизнес-объекты приложений, не проходя через слой преобразования, такой как SOAP или XML. Поведение на стороне сервера, хотя и реализовано на Java, обеспечивает уникальный собственный кеш для приложений на C ++ и .NET. Объекты приложения могут управляться в куче процессов C ++ и распределяться по другим процессам с использованием общего представления «on-the-wire» для объектов. Сериализованный объект C ++ может быть непосредственно разделен на части как эквивалентный объект Java или C #. Изменение бизнес-объекта на одном языке может инициировать уведомления в приложениях, написанных на других поддерживаемых языках.

Управление ресурсами в Apache Geode

Общее представление

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

Зачем управлять ресурсами?

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

Память - ключевой ресурс,которым нужно управлять

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

Geode - управление ресурсами

Ниже описано, как Geode реализует управление ресурсами для ресурсов, участвующих в распределенной системе Geode.

Память

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

 "Вытеснение" данных

Geode позволяет каждому серверу кэша задавать политику данных для управления объемом данных, хранящимся на сервере. Если используется "вытеснение", то это автоматически означает, что Geode используется в качестве кэша, и если запись не может быть найдена в кэше, существует альтернативное хранилище данных, из которого она может быть загружена.

Восстановление равновесия

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

Менеджер ресурсов Geode

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

Переполнение Диска

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

Управление объемом памяти клиентских подписок

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

Сеть

Серверы кэша Geode могут быть сконфигурированы для использования TCP, надежной одноадресной или надежной мультиадресной рассылки в качестве протокола связи для обмена метаданными, а также для распределения данных по кластеру серверов. Клиентские приложения используют TCP для связи с серверами. Клиенты обычно подключаются к нескольким серверам в зависимости от потребностей в доступе к данным, а также для обеспечения избыточности очередей подписки. Кластеры серверов, использующие протокол TCP для взаимодействия друг с другом, также объединяют свои соединения в пул и используют алгоритмы времени простоя для возврата соединений в пул или закрытия соединений, когда они не нужны. Каждый сервер можно настроить с максимальным лимитом клиента. В дополнение к этому Geode позволяет клиентам настраивать пользовательский датчик нагрузки, который по существу сообщает общий коэффициент нагрузки на виртуальной машине сервера. Пользовательский датчик нагрузки реализует предопределенный интерфейс, и информация, которую он предоставляет, используется для перенаправления существующих и новых клиентских подключений к серверам, которые слегка загружены для обеспечения лучшего QoS. Клиенты также объединяют свои соединения с серверами, сдают их в аренду потокам приложений для доступа к данным на сервере и возвращают соединения в пул, когда поток приложений завершит доступ к данным. Срок действия клиентских подключений в пуле может истечь, что дает кластеру серверов возможность балансировать подключения и гарантировать, что каждый сервер сможет оптимально обслуживать своих клиентов. И последнее, но не менее важное: возможность эффективной сериализации объектов по сети с использованием протокола нейтрального языка и передачи дельт объектов получателям ограничивает использование пропускной способности и позволяет приложениям эффективно использовать этот ресурс в сочетании с другими ресурсами, влияющими на качество обслуживания приложений. Протокол DataSerializable в Geode обеспечивает чрезвычайно байт-эффективное представление объекта на проводе, уменьшая потребление полосы пропускания, когда объект передается через границы машины. Эффективное представление провода также уменьшает использование CPU, когда байты передаются по проводу. В большинстве реальных развертываний, когда объект часто обновляется, есть возможность определить, какая часть объекта была изменена, а затем сериализовать только эти изменения и применить их в другом месте, без ущерба для согласованности данных (aka Delta Propagation). Это дополнительно оптимизирует протокол wire, уменьшает образование мусора, улучшает использование полосы пропускания и уменьшает использование CPU.

CPU

Кластер Geode обеспечивает распределенное управление данными для приложений с очень высокой пропускной способностью и очень низкими задержками. Он получает обновления данных из множества различных источников и должен распространять их среди соответствующих членов кластера, чтобы обеспечить согласованность данных для приложений. Все это делает каждый сервер распараллеленной сущностью, которая интенсивно использует многопоточность для выполнения своей работы. Geode эффективно использует пулы потоков и очереди для предоставления некоторых ключевых преимуществ поэтапных архитектур, управляемых событиями (Высокий параллелизм, подготовлять нагрузки, масштабируемый I / O и так далее).

Диск

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

Размеры Geode - кластера

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

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

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

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

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

Требования и допущения

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

  • Подмножество репрезентативных данных: чем ближе реальные данные, тем лучше.
  • Соответствующее подмножество рабочей нагрузки, максимально точно соответствующее рабочей нагрузке.
  • Аппаратные ресурсы для тестирования, в идеале та же категория, которая будет использоваться в производстве (те же ресурсы CPU, памяти, сети и диска на узел). Как минимум, необходимо запустить 3 узла данных Geode только для начала, а затем добавить по крайней мере еще несколько узлов, чтобы проверить масштабируемость. Также понадобится такое же количество хостов для клиентов Geode, чтобы создать адекватную рабочую нагрузку.

Архитектурные и конструктивные соображения

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

Сериализация

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

Запись

Ниже перечислены факторы, которые могут оказать значительное влияние на объем памяти для данных на основе записи, а также производительность:

  • Выбор типа geode-области: Разные регионы имеют разные накладные расходы на вход. Эти накладные расходы документированы, а также включены в таблицу размеров.
  • Выбор механизма сериализации: Geode предлагает несколько вариантов сериализации, а также возможность сериализации значений. Как упоминалось выше, Geode PDX сериализация является обычно рекомендуемым механизмом сериализации из-за его пространства и производительности преимущества.
  • Выбор ключей: Более малые и более просто ключи более эффективны.
  • Использование индексов: Индексирование влечет за собой накладные расходы на запись.


Масштабируемость секционированной области

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

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

Очереди Geode

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

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


Переход от memcached к gemcached

Gemcached

Серверы Geode можно настроить для работы с протоколом memcached. Сервер Geode является memcapable, это означает, что любое существующее memcached приложение может быть указано на кластер Geode с нулевыми строками изменения кода. Все, что вам нужно сделать, это указать порт и/или протокол (двоичный или ASCII) при запуске сервера Geode.

gfsh> start server --name=server1 --memcached-port=11211 --memcached-protocol=BINARY

Сервер Geode создает область с именем “gemcached " для хранения всех memcached данных. Регион gemcached по умолчанию является разделом.

Настройка gemcached

Чтобы изменить атрибуты региона для региона gemcached, используйте cache.xml для определения необходимых атрибутов. Пример cache.xml ниже показывает, как изменить общее количество сегментов на 251. Затем используйте cache.xml при запуске сервера Geode:

gfsh> start server --name=server1 --memcached-port=11211 --memcached-protocol=BINARY --cache-xml-file=/path/to/cache.xml

Зачем отказываться от memcached?

Одна из фундаментальных проблем memcached заключается в том, что он поддерживает только “кэш-сторону” , т. е. приложение отвечает за обновление кэша, а также базы данных. В результате:

  • Возможность несогласованности между кэшем и базой данных
  • Загрязнение бизнес-логики в каждом приложении одинаковыми проблемами инфраструктуры.

Рисунок 1 - Использование memcached

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

Устаревший кэш

Клиент может умереть сразу после того, как он обновил БД, но до того, как он записал изменение в memcached. Все остальные клиенты не обращают внимания на измененную БД и продолжают обслуживать устаревшие данные.

Несогласованный кэш

Приложения могут использовать команду CAS, чтобы гарантировать, что они не перезаписывают данные, которые они не видели. Для использования CAS рабочий процесс: чтение из memcached для получения идентификатора cas (таким образом, мы всегда должны делать одно дополнительное чтение для каждой записи), затем обновить БД с последующей записью в memcached с помощью операции CAS, если операция CAS не удалась, аннулировать/уничтожить кэшированную запись. Даже при использовании CAS существует небольшое окно, в котором БД и кэш по-прежнему несовместимы. Предположим, у вас есть 2 клиента (c1 и c2), пытающиеся записать один и тот же ключ (K). Оба клиента сначала получат один и тот же идентификатор CAS из memcached, обновят БД, а затем обновят memcached. С момента сбоя CAS до тех пор, пока приложение не развернется, чтобы уничтожить ключ, memcached будет иметь устаревшие данные. Если клиент умирает перед отправкой уничтожить, кэш и данные будут навсегда несовместимы.

Преимущества gemcached

Рисунок 2 - Использование gemcached

С помощью Gemcached вы можете использовать Geode в качестве кэша для записи.

Это означает, что приложению больше не нужно взаимодействовать с базой данных, что упрощает код приложения. Все операции чтения и записи базы данных выполняются через Geode. Для чтения данных из БД вы можете использовать Geode CacheLoader, а для записи данных обратно в БД-AsyncEventListener. Ниже приведено как вышеуказанные проблемы решаются с помощью gemcached.

Устаревший кэш

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

Несогласованный кэш

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

Запуск на хост-машине

Каждый хост Apache Geode должен удовлетворять небольшому набору предварительных условий.

Требования к хост-машине

Каждая машина, которая будет запускать Apache Geode, должна отвечать следующим требованиям:

  • Java SE Development Kit 8 с обновлением 121 или более поздним обновлением версии 8.
  • Системные часы установлены на правильное время и на службу синхронизации времени, например Network Time Protocol (NTP). Правильные отметки времени позволяют выполнять следующие действия:
    • Журналы, которые полезны для устранения неполадок. Синхронизированные метки времени гарантируют, что сообщения журнала с разных хостов могут быть объединены для воспроизведения точной хронологической истории.
    • Совокупная статистика времени на уровне продукта и прикладного уровня.
    • Точный мониторинг системы Geode со сценариями и другими инструментами, которые считывают системную статистику и файлы журналов.
  • Имя хоста и файлы хоста правильно настроены для машины. Имя хоста и конфигурация файла хоста могут влиять на функции gfsh и Pulse.
  • Отключить файлы cookie TCP SYN. Большинство установок Linux по умолчанию используют SYN-файлы cookie для защиты системы от вредоносных атак, которые падают TCP SYN-пакетами, но эта функция несовместима со стабильными и загруженными кластерами Geode. Вместо этого реализации безопасности должны быть направлены на предотвращение атак путем размещения кластеров Geode серверов за расширенной защитой брандмауэра.

Чтобы отключить cookie SYN навсегда:

  • Отредактируйте файл /etc/sysctl.conf, чтобы включить следующую строку:
net.ipv4.tcp_syncookies = 0

Установка этого значения в ноль отключает файлы cookie SYN.

  • Перезагрузить sysctl.conf:
sysctl -p

Установка[3]

Используйте дистрибутив ZIP или TAR для установки Apache Geode на каждой физической и виртуальной машине, на которой будет запущен Apache Geode.

  • На Unix

Установите переменную среды JAVA_HOME.

JAVA_HOME=/usr/java/jdk1.8.0_121
export JAVA_HOME

Загрузите источник проекта со страницы выпуска, найденной по адресу http://geode.apache.org, и распакуйте исходный код. Внутри каталога, содержащего распакованный исходный код, скомпонуйте без тестов:

$ ./gradlew build -Dskip.tests = true

Или, постройте с помощью тестов:

$ ./gradlew build

Проверьте правильность установки, вызвав "gfsh" для вывода информации о версии. На платформах Linux / Unix версия будет похожа на:

$ cd geode-assembly/build/install/apache-geode
$ bin/gfsh version
v1.1.0
  • На Windows

Установите переменную среды JAVA_HOME. Например:

$ set JAVA_HOME="C:\Program Files\Java\jdk1.8.0_121" 

Установите Gradle, версию 2.3 или более новую версию. Загрузите источник проекта со страницы выпуска, найденной по адресу http://geode.apache.org, и распакуйте исходный код. В папке, содержащей распакованный исходный код, выполните сборку без тестов:

$ gradle build -Dskip.tests=true

Или, постройте с помощью тестов:

$ gradle build

Проверьте установку, вызвав gfsh для вывода информации о версии.

$ cd geode-assembly\build\install\apache-geode\bin
$ gfsh.bat version
v1.1.0
  • Установка из .zip или .tar

Загрузите файл .zip или .tar со страницы выпуска, найденной по адресу http://geode.apache.org. Разархивируйте ZIP-файл или .tar, где path_to_product - это абсолютный путь, а имя файла зависит от номера версии. Для формата .zip:

$ unzip apache-geode-1.1.0.zip -d path_to_product

Для формата .tar:

$ tar -xvf apache-geode-1.1.0.tar -C path_to_product

Установите переменную среды JAVA_HOME. На платформах Linux / Unix:

JAVA_HOME=/usr/java/jdk1.8.0_121
export JAVA_HOME

На платформах Windows:

set JAVA_HOME="C:\Program Files\Java\jdk1.8.0_121"

Добавьте сценарии Geode в переменную среды PATH. На платформах Linux / Unix:

PATH=$PATH:$JAVA_HOME/bin:path_to_product/bin
export PATH

На платформах Windows:

set PATH=%PATH%;%JAVA_HOME%\bin;path_to_product\bin 

Чтобы проверить установку, введите gfsh-версию в командной строке и обратите внимание, что на выводе указана установленная версия Geode. Например:

$ gfsh version
v1.1.0

Для получения более подробной информации о версии, такой как дата сборки, номер сборки и используемая версия JDK, вызовите:

$ gfsh version --ful

Настройка ClassPath

Чтобы упростить настройки среды CLASSPATH, Geode организовал все библиотеки приложений, необходимые для процессов Geode, в файлы * -dependencies.jar. Все JAR-файлы зависимостей находятся в каталоге path_to_product / lib. При запуске процесса сервера или локатора с использованием gfsh файлы приложения JAR автоматически загружаются в CLASSPATH процесса из двух каталогов:

  • path_to_product/lib/
  • path_to_product/extensions/

Чтобы внедрить Geode в ваше приложение, добавьте path_to_product / lib / geode-dependencies.jar в свой CLASSPATH. Изменение CLASSPATH в управляемых gfsh процессах' Существует два варианта обновления CLASSPATH процессов Geode и локаторов, которые запускаются в командной строке gfsh. Вариант 1: Задайте параметр -classpath при запуске процесса. Например, чтобы изменить CLASSPATH локатора:

gfsh> start locator --name=locator1 --classpath=/path/to/applications/classes.jar

И для изменения CLASSPATH сервера:

gfsh> start server --name=server1 --classpath=/path/to/applications/classes.jar

Классы приложений, поставляемые в качестве аргументов опции -classpath, добавляются к серверу или CLASSPATH локатора, начиная со второй позиции. Первая запись в CLASSPATH зарезервирована для основного файла Geode jar по соображениям безопасности. Вариант 2: Определите переменную среды CLASSPATH в среде ОС. Затем укажите параметр -include-system-classpath при запуске процесса. Например:

gfsh> start locator --name=locator1 --include-system-classpath=true

То же самое можно сделать и для серверных процессов:

gfsh> start server --name=server1 --include-system-classpath=true

Этот параметр добавляет содержимое переменной CLASSPATH системы в локатор или CLASSPATH сервера при запуске. Указание этой опции без значения устанавливает ее значение true. Настройка CLASSPATH для приложений и автономных процессов Java Если вы запускаете Geode-процесс программным способом (автономным или встроенным), рекомендуется указать CLASSPATH при выполнении программы с помощью параметра командной строки java -classpath или java -cp. Этот метод предпочтительнее устанавливать CLASSPATH в качестве переменной среды, поскольку он позволяет устанавливать значение отдельно для каждого приложения, не затрагивая другие приложения. Например, чтобы запустить процесс локатора Geode с помощью API LocatorLauncher, можно выполнить следующее в командной строке:

prompt# java -cp "path_to_product/lib/geode-dependencies.jar"
org.apache.geode.distributed.LocatorLauncher start locator1
<locator-launcher-options>

Чтобы запустить серверный процесс Geode с использованием API ServerLauncher:

prompt# java -cp "path_to_product/lib/geode-dependencies.jar:/path/to/your/applications/classes.jar"
org.apache.geode.distributed.ServerLauncher start server1
<server-launcher-options>

Обратите внимание, что в дополнение к файлу * -dependencies.jar, связанному с процессом, также необходимо указать какие-либо пользовательские JAR-приложения, к которым вы хотите получить доступ в вашем Geode-процессе. Чтобы запустить приложение со встроенным кэшем:

java -cp "path_to_product/lib/geode-dependencies.jar:/path/to/your/applications/classes.jar"
com.mycompany.package.ApplicationWithEmbeddedCache

Удаление

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

Использование

Хост-машиной является Windows 10.

Запуск

С помощью консоли переходим в папку с Apache Geode. JAVA_HOME и Gradle уже прописаны. В терминальном окне используйте интерфейс командной строки gfsh для запуска локатора. Apache Geode gfsh (произносится как «jee-fish») обеспечивает единый интуитивный интерфейс командной строки, из которого вы можете запускать, управлять и контролировать процессы, данные и приложения Apache Geode

gfsh
    _________________________     __
   / _____/ ______/ ______/ /____/ /
  / /  __/ /___  /_____  / _____  /
 / /__/ / ____/  _____/ / /    / /
/______/_/      /______/_/    /_/    1.7

Monitor and Manage Geode
gfsh>

В командной строке gfsh введите команду start locator и укажите имя локатора:

gfsh>start locator --name=locator1
Starting a Geode Locator in /home/username/my_geode/locator1...
.................................
Locator in /home/username/my_geode/locator1 on ubuntu.local[10334] as locator1 is currently online.
Process ID: 3529
Uptime: 18 seconds
Geode Version: 1.7
Java Version: 1.8.0_121
Log File: /home/username/my_geode/locator1/locator1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true -Dgemfire.load-cluster-configuration-from-dir=false
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path: /home/username/Apache_Geode_Linux/lib/geode-core-1.0.0.jar:
/home/username/Apache_Geode_Linux/lib/geode-dependencies.jar

Successfully connected to: JMX Manager [host=10.118.33.169, port=1099]

Cluster configuration service is up and running.

Если вы запускаете локатор запуска из gfsh без указания имени члена, gfsh автоматически выбирает случайное имя участника. Это полезно для автоматизации.

Запуск Pulse

Запустите инструмент Pulse Monitoring на основе браузера. Pulse - это веб-приложение, которое предоставляет графическую панель мониторинга для мониторинга жизненно важного состояния и работоспособности кластеров, членов и регионов Geode в реальном времени.

gfsh>start pulse

Эта команда запускает Pulse и автоматически соединяет вас с Диспетчером JMX, запущенным в Locator. На экране ввода введите логин "admin" и пароль "admin" по умолчанию. Приложение Pulse теперь отображает локатор, который вы только что запустили (locator1).

Сервер

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

gfsh>start server --name=server1 --server-port=40411 

Эти команды запускают кэш-сервер с именем «server1» в указанном порту 40411. Если вы запускаете сервер запуска из gfsh без указания имени участника, gfsh автоматически выбирает случайное имя участника.

Создание реплицируемой постоянной области

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

  • Создайте реплицированный, устойчивый регион:
gfsh>create region --name=regionA --type=REPLICATE_PERSISTENT
Member  | Status
------- | --------------------------------------
server1 | Region "/regionA" created on "server1"
  • Используйте командную строку gfsh для просмотра списка областей в кластере.
gfsh>list regions
List of regions
---------------
regionA
  • Список членов кластера. Созданный локатор и сервер кэша отображаются в списке:
gfsh>list members
  Name       | Id
------------ | ---------------------------------------
Coordinator: | 192.0.2.0(locator1:3529:locator)<ec><v0>:59926
locator1     | 192.0.2.0(locator1:3529:locator)<ec><v0>:59926
server1      | 192.0.2.0(server1:3883)<v1>:65390
  • Чтобы просмотреть специфику области, введите следующее:
gfsh>describe region --name=regionA
..........................................................
Name            : regionA
Data Policy     : persistent replicate
Hosting Members : server1

Non-Default Attributes Shared By Hosting Members

 Type  | Name | Value
------ | ---- | -----
Region | size | 0

Манипуляция данными в области

Apache Geode управляет данными как пары ключ / значение. В большинстве приложений программа Java добавляет, удаляет и изменяет сохраненные данные. Вы также можете использовать команды gfsh для добавления и извлечения данных.

  • Запустите команду put, чтобы добавить некоторые данные в область:
gfsh>put --region=regionA --key="1" --value="one"
Result      : true
Key Class   : java.lang.String
Key         : 1
Value Class : java.lang.String
Old Value   : <NULL>

gfsh>put --region=regionA --key="2" --value="two"
Result      : true
Key Class   : java.lang.String
Key         : 2
Value Class : java.lang.String
Old Value   : <NULL>
  • Выполните следующую команду для извлечения данных из области:
gfsh>query --query="select * from /regionA"

Result     : true
startCount : 0
endCount   : 20
Rows       : 2

Result
------
two
one

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

  • Остановите кеш-сервер, используя следующую команду:
gfsh>stop server --name=server1
Stopping Cache Server running in /home/username/my_geode/server1 on ubuntu.local[40411] as server1...
Process ID: 3883
Log File: /home/username/my_geode/server1/server1.log
....
  • Перезапустите сервер кэша, используя следующую команду:
gfsh>start server --name=server1 --server-port=40411##i##
  • Выполните следующую команду для получения данных из области снова - обратите внимание, что данные все еще доступны:
gfsh>query --query="select * from /regionA"

Result     : true
startCount : 0
endCount   : 20
Rows       : 2

Result
------
two
one

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

Эффект репликации

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

  • Запустите второй сервер кэша:
gfsh>start server --name=server2 --server-port=40412
*Запустите командуdescribe region для просмотра информации о regionA:
gfsh>describe region --name=regionA
..........................................................
Name            : regionA
Data Policy     : persistent replicate
Hosting Members : server1
                  server2

Non-Default Attributes Shared By Hosting Members

 Type  | Name | Value
------ | ---- | -----
Region | size | 2

Обратите внимание, что вам не нужно снова создавать regionA для server2. Результат команды показывает, что regionA размещен как на сервере server1, так и на сервере server2. Когда gfsh запускает сервер, он запрашивает конфигурацию из службы конфигурации кластера, которая затем распределяет общую конфигурацию на любые новые серверы, соединяющие кластер.

  • Добавьте третий блок данных:
gfsh>put --region=regionA --key="3" --value="three"
Result      : true
Key Class   : java.lang.String
Key         : 3
Value Class : java.lang.String
Old Value   : <NULL>
  • Остановите первый сервер кеша с помощью следующей команды:
gfsh>stop server --name=server1
Stopping Cache Server running in /home/username/my_geode/server1 on ubuntu.local[40411] as server1...
Process ID: 4064
Log File: /home/username/my_geode/server1/server1.log
....
  • Извлечь данные из оставшегося сервера кеша:
fsh>query --query="select * from /regionA"

Result     : true
startCount : 0
endCount   : 20
Rows       : 3

Result
------
two
one
three
  • Остановить оставшийся сервер кеша:
gfsh>stop server --name=server2
Stopping Cache Server running in /home/username/my_geode/server2 on ubuntu.local[40412] as server2...
Process ID: 4185
Log File: /home/username/my_geode/server2/server2.log
.....

Перезапустить кэш-серверы параллельно

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

  • Запустить server1. Поскольку regionA реплицируется и сохраняется, ему нужны данные с другого сервера для запуска и ожидания запуска сервера:
gfsh>start server --name=server1 --server-port=40411
Starting a Geode Server in /home/username/my_geode/server1...
............................................................................
............................................................................

Обратите внимание: если вы заглянете в файл server1.log для перезапущенного сервера, вы увидите сообщение журнала, похожее на следующее:

[info 2015/01/14 09:08:13.610 PST server1 <main> tid=0x1] Region /regionA has pot
entially stale data. It is waiting for another member to recover the latest data.
  My persistent id:

    DiskStore ID: 8e2d99a9-4725-47e6-800d-28a26e1d59b1
    Name: server1
    Location: /192.0.2.0:/home/username/my_geode/server1/.

  Members with potentially new data:
  [
    DiskStore ID: 2e91b003-8954-43f9-8ba9-3c5b0cdd4dfa
    Name: server2
    Location: /192.0.2.0:/home/username/my_geode/server2/.
  ]
  Use the "gfsh show missing-disk-stores" command to see all disk stores that
are being waited on by other members.
  • Во втором окне терминала смените каталоги на рабочий стол с нуля (например, my_geode) и запустите gfsh:
[username@localhost ~/my_geode]$ gfsh
    _________________________     __
   / _____/ ______/ ______/ /____/ /
  / /  __/ /___  /_____  / _____  /
 / /__/ / ____/  _____/ / /    / /
/______/_/      /______/_/    /_/    1.7

Monitor and Manage Geode
  • Для подключения к кластеру выполните следующую команду:
gfsh>connect --locator=localhost[10334]
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=ubuntu.local, port=1099] ..
Successfully connected to: [host=ubuntu.local, port=1099]
  • Запуск Server2:
gfsh>start server --name=server2 --server-port=40412

Когда server2 запускается, обратите внимание, что server1 завершает запуск в первом окне gfsh:

Server in /home/username/my_geode/server1 on ubuntu.local[40411] as server1 is currently online.
Process ID: 3402
Uptime: 1 minute 46 seconds
Geode Version: 1.7
Java Version: 1.8.0_121
Log File: /home/username/my_geode/server1/server1.log
JVM Arguments: -Dgemfire.default.locators=192.0.2.0[10334] -Dgemfire.use-cluster-configuration=true
-XX:OnOutOfMemoryError=kill -KILL %p -Dgemfire.launcher.registerSignalHandlers=true
-Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path: /home/username/Apache_Geode_Linux/lib/geode-core-1.0.0.jar:
/home/username/Apache_Geode_Linux/lib/geode-dependencies.jar
  • Убедитесь, что локатор и два сервера запущены:
gfsh>list members
  Name       | Id
------------ | ---------------------------------------
Coordinator: | ubuntu(locator1:2813:locator)<ec><v0>:46644
locator1     | ubuntu(locator1:2813:locator)<ec><v0>:46644
server2      | ubuntu(server2:3992)<v8>:21507
server1      | ubuntu(server1:3402)<v7>:36532
  • Запустите запрос, чтобы убедиться, что все данные, введенные с помощью команд put, доступны:
gfsh>query --query="select * from /regionA"

Result     : true
startCount : 0
endCount   : 20
Rows       : 5

Result
------
one
two
four
Three

NEXT_STEP_NAME : END
  • Остановите server2 с помощью следующей команды:
gfsh>stop server --dir=server2
Stopping Cache Server running in /home/username/my_geode/server2 on 192.0.2.0[40412] as server2...
Process ID: 3992
Log File: /home/username/my_geode/server2/server2.log
....
  • Запустите запрос, чтобы убедиться, что все данные, введенные с помощью команд put, по-прежнему доступны:
gfsh>query --query="select * from /regionA"

Result     : true
startCount : 0
endCount   : 20
Rows       : 5

Result
------
one
two
four
Three

NEXT_STEP_NAME : END

Завершение работы

Чтобы закрыть кластер, выполните следующие действия:

  • В текущем сеансе gfsh остановите кластер:
gfsh>shutdown --include-locators=true
  • При появлении запроса введите «Y», чтобы подтвердить выключение кластера.
As a lot of data in memory will be lost, including possibly events in queues,
do you really want to shutdown the entire distributed system? (Y/n): Y
Shutdown is triggered

gfsh>
No longer connected to ubuntu.local[1099].
gfsh>
  • Введите exit, чтобы выйти из оболочки gfsh.

Источники

  1. Apache Geode. Official development web site. // Apache Geode. [2016]. Дата обновления: 07.10.2018. URL: http://geode.apache.org (дата обращения: 07.10.2018).
  2. Apache. Apache Geode Wiki. // cwiki Apache. [2016]. Дата обновления: 07.10.2018. URL: https://cwiki.apache.org/confluence/display/geode (дата обращения: 07.10.2018).
  3. Apache. Apache Geode Github. // Github. [2019]. Дата обновления: 08.10.2018. URL: https://github.com/apache/geode (дата обращения: 08.10.2018).