Запуск Apache Cassandra на виртуальных машинах Azure

Внимание

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

В этой статье описываются аспекты производительности для запуска Apache Cassandra на виртуальных машинах Azure.

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

Управляемый экземпляр Azure для Apache Cassandra

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

Размеры виртуальных машин Azure и типы дисков

Рабочие нагрузки Cassandra в Azure обычно используют Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 или Standard_E16s_v5 виртуальных машин. Рабочие нагрузки Cassandra получают больше памяти на виртуальной машине, поэтому рассмотрите оптимизированные размеры виртуальных машин, например Standard_DS14_v2 или Standard_E16s_v5, или оптимизированные для локального хранилища размеры, такие как Standard_L16s_v3.

Для обеспечения долговечности журналы фиксации и данные обычно хранятся в наборе полос с от двух до четырех 1-ТБ Премиальных SSD (P30).

Узлы Cassandra не должны быть перегружены данными. Рекомендуется иметь не более 1 до 2 ТБ данных на виртуальную машину и достаточно свободного места для сжатия. Чтобы достичь максимально возможной объединенной пропускной способности и операций ввода-вывода в секунду с помощью SSD уровня "Премиум", рекомендуется создать набор полос из нескольких дисков размером 1 ТБ, а не использовать один диск размером 2 ТБ или 4 ТБ. Например, на виртуальной машине DS14_v2 четыре диска емкостью 1 ТБ имеют максимальное количество операций ввода-вывода в секунду 4 × 5000 = 20 КБ по сравнению с 7,5 КБ для одного диска емкостью 4 ТБ.

Оцените Azure Ultra-диски для нагрузок Cassandra, требующих меньшей емкости дисков. Они могут обеспечить более высокие IOPS/пропускную способность и снизить задержку на размерах виртуальных машин, таких как Standard_E16s_v5 и Standard_D16s_v5.

Для рабочих нагрузок Cassandra, которые не нуждаются в устойчивом хранилище, то есть, где данные можно легко восстановить из другого носителя хранилища, рассмотрите возможность использования Standard_L16s_v3 или Standard_L16s_v2 виртуальных машин. Эти размеры виртуальных машин имеют большие и быстрые локальные временные диски NVM Express (NVMe).

Ускорение работы в сети

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

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

Для ускорения сети требуется поддерживаемый дистрибутив Linux с последними драйверами. Дополнительные сведения см. в статье "Создание виртуальной машины Linux с ускорением сети".

Кэширование диска данных виртуальной машины Azure

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

Рабочие нагрузки с интенсивным чтением и случайным чтением, такие как Cassandra, выигрывают от более низкой задержки чтения, даже несмотря на то, что режим кэширования имеет более низкие ограничения пропускной способности, чем режим без кэширования. (Например, DS14_v2 виртуальные машины имеют максимальную кэшированную пропускную способность 512 МБИТ/с и некшированные 768 МБИТ/с.)

Кэширование ReadOnly особенно полезно для временных рядов Cassandra и других рабочих нагрузок, где рабочий набор данных помещается в кэш узла и данные не постоянно перезаписываются. Например, DS14_v2 предоставляет размер кэша размером 512 ГБ, который может хранить до 50% данных из узла Cassandra с плотностью данных 1–2 ТБ.

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

Упреждающее чтение в Linux

В большинстве дистрибутивов Linux, доступных для Azure в Microsoft Marketplace, значение по умолчанию для настройки предварительной выборки блочных устройств составляет 4096 КБ. Чтение I/OS Cassandra обычно случайное и относительно небольшое. Таким образом, большое упреждающее чтение приводит к потере пропускной способности путем чтения ненужных частей файлов.

Чтобы уменьшить ненужное упреждающее чтение, установите для блочного устройства Linux настройку упреждающего чтения на 8 КБ. (См. рекомендуемые рабочие параметры в документации по DataStax.)

Установите упреждающее чтение 8 КБ для всех блочных устройств в стрип-наборе и на самом матричном устройстве (например, /dev/md0).

Размер фрагмента дискового массива mdadm

При запуске Cassandra в Azure обычно создается чередующийся набор mdadm (т. е. RAID 0) из нескольких дисков данных, чтобы увеличить общую пропускную способность диска и число операций ввода-вывода в секунду ближе к ограничениям виртуальной машины. Оптимальный размер полосы данных дисков — это параметр, зависящий от приложения. Например, для рабочих нагрузок SQL Server OLTP рекомендуется 64 КБ. Для рабочих нагрузок хранилища данных рекомендуется 256 КБ.

Наши тесты не обнаружили существенных различий между размерами блоков 64 КБ, 128 КБ и 256 КБ для нагрузок на чтение в Cassandra. Кажется, у размера блока 128 КБ есть небольшое, едва заметное преимущество. Поэтому рекомендуется использовать следующие подходы:

  • Если вы уже используете размер блока 64 K или 256 K, это не имеет смысла перестроить массив дисков для использования размера 128-K.

  • В новой конфигурации имеет смысл использовать 128 КБ с самого начала.

Файловая система журнала фиксации

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

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

На основе наших тестов Cassandra в CentOS 7.x может иметь более низкую производительность записи, если журналы фиксации находятся в файловой системе xfs и ext4. Включение сжатия журнала фиксации повышает производительность xfs до уровня ext4. В наших тестах сжатая xfs работала так же хорошо, как сжатая и несжатая ext4.

Измерение базовой производительности виртуальной машины

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

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

Размер документа

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

Коэффициент репликации

Большинство рабочих нагрузок Cassandra используют коэффициент репликации (RF) 3 при использовании подключенных дисков премиум-класса и даже 5 при использовании временных или эфемерных локальных дисков. Количество узлов в Cassandra Ring должно быть кратным коэффициенту репликации. Например, RF, равный 3, подразумевает кольцо из 3, 6, 9 или 12 узлов, а RF, равный 5 — из 5, 10, 15 или 20 узлов. При использовании RF больше 1 и уровня согласованности LOCAL_QUORUM, это нормально, что производительность операций чтения и записи обычно ниже, чем при выполнении той же рабочей нагрузки с RF 1.

Кэширование страниц в Linux

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

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

Репликация между несколькими центрами обработки данных

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

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

Важно измерить базовый показатель задержки при передаче данных между регионами. Задержка в сети между регионами может быть в 10–100 раз выше, чем задержка в пределах региона. Ожидается задержка в появлении данных во втором регионе при использовании консистенции записи LOCAL_QUORUM или ожидается значительное снижение производительности операций записи при использовании консистенции записи EACH_QUORUM.

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

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

Конфигурация механизма направленной отправки

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Главный автор:

Другой участник:

Чтобы увидеть непубличные профили в LinkedIn, войдите в LinkedIn.

Следующие шаги

Дополнительные сведения о общих параметрах Cassandra, не относящихся к Azure, см. в следующем разделе:

  • Last updated on