Запуск Apache Cassandra на виртуальных машинах Azure
Внимание
В этой статье содержатся ссылки на CentOS, дистрибутив Linux, который является концом жизни (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.
В этой статье описываются рекомендации по производительности для запуска Apache Cassandra в Azure Виртуальные машины.
Эти рекомендации основаны на результатах тестов производительности, которые можно найти на GitHub. Эти рекомендации следует использовать в качестве базовых показателей, а затем протестировать свою собственную рабочую нагрузку на предмет соответствия им.
Управляемый экземпляр Azure для Apache Cassandra
Если вы ищете более автоматизированную службу для запуска Apache Cassandra в Azure Виртуальные машины, рассмотрите возможность использования Azure Управляемый экземпляр для Apache Cassandra. Эта служба автоматизирует развертывание, управление (исправление и работоспособность узла) и масштабирование узлов в кластере Apache Cassandra. Кроме того, она предоставляет возможность создания гибридных кластеров, поэтому центры обработки данных Apache Cassandra, развернутые в Azure, могут присоединяться к существующему локальному или стороннему Cassandra Ring. Служба развертывается с помощью 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 ТБ (P30).
Узлы Cassandra не должны быть слишком плотными. Рекомендуется хранить не более 1–2 ТБ данных на каждой виртуальной машине и иметь достаточно свободного места для сжатия. Для достижения максимально возможных объединенной пропускной способности и операций ввода-вывода в секунду с использованием управляемых дисков уровня "Премиум" рекомендуется создать чередующийся набор из нескольких дисков объемом 1 ТБ, а не использовать один диск объемом 2 или 4 ТБ. Например, на виртуальной машине DS14_v2 четыре диска емкостью 1 ТБ имеют максимальное количество операций ввода-вывода в секунду 4 × 5000 = 20 КБ по сравнению с 7,5 КБ для одного диска емкостью 4 ТБ.
Оцените диски Azure Ценовой категории "Ультра" для рабочих нагрузок Cassandra, требующих меньшей емкости диска. Они могут обеспечить более высокую скорость ввода-вывода в секунду или пропускную способность, а также снизить задержку в размерах виртуальных машин, таких как Standard_E16s_v5 и Standard_D16s_v5.
Для рабочих нагрузок Cassandra, которые не нуждаются в устойчивом хранилище, то есть где данные можно легко восстановить из другого носителя хранилища, рассмотрите возможность использования Standard_L16s_v3 или Standard_L16s_v2 виртуальных машин. Эти размеры виртуальных машин имеют большие и быстрые локальные временные диски NVM Express (NVMe).
Дополнительные сведения см. в статье Сравнение производительности локальных/временных и подключенных/постоянных дисков Azure (GitHub).
Ускорение работы в сети
Узлы Cassandra активно используют сеть для отправки и получения данных с клиентской виртуальной машины, а также для связи между узлами с целью репликации. Для оптимальной производительности виртуальной машине Cassandra выгодно использовать высокопроизводительную сеть с низкой задержкой.
Мы рекомендуем включить ускорение работы в сети на сетевом адаптере узла Cassandra и на виртуальных машинах, на которых работают клиентские приложения, обращающиеся к Cassandra.
Для ускорения сети требуется современное дистрибутив Linux с последними драйверами, такими как Cent OS 7.5+ или Ubuntu 16.x/18.x. Дополнительные сведения см. в статье Создание виртуальной машины Linux с ускоренной сетью.
Кэширование диска данных виртуальной машины Azure
Рабочие нагрузки чтения Cassandra работают наилучшим образом при низкой задержке диска произвольного доступа. Мы рекомендуем использовать управляемые диски Azure с включенным кэшированием только для чтения. Кэширование только для чтения обеспечивает меньшую среднюю задержку, так как данные считываются из кэша на узле, а не из cерверного хранилища.
Рабочие нагрузки с интенсивным чтением и случайным чтением, такие как Cassandra, выигрывают от более низкой задержки чтения, даже несмотря на то, что режим кэширования имеет более низкие ограничения пропускной способности, чем режим без кэширования. (Например, DS14_v2 виртуальные машины имеют максимальную кэшированную пропускную способность 512 МБИТ/с и некшированные 768 МБИТ/с.)
Кэширование ReadOnly особенно полезно для временных рядов Cassandra и других рабочих нагрузок, где рабочий набор данных помещается в кэш узла и данные не постоянно перезаписываются. Например, DS14_v2 обеспечивает размер кэша 512 ГБ, в котором может храниться до 50% данных с узла Cassandra с плотностью данных 1–2 ТБ.
При включении кэширования ReadOnly не существует существенного снижения производительности, поэтому для всех, кроме наиболее тяжелых рабочих нагрузок, рекомендуется использовать кэшированный режим.
Дополнительные сведения см. в статье Сравнение конфигураций кэширования диска данных виртуальной машины Azure (GitHub).
Упреждающее чтение в Linux
В большинстве дистрибутивов Linux в Azure Marketplace значение упреждающего чтения блочного устройства по умолчанию составляет 4096 КБ. Чтение I/OS Cassandra обычно случайное и относительно небольшое. Таким образом, наличие значительного упреждающего чтения приводит к потере пропускной способности за счет чтения ненужных частей файлов.
Чтобы свести к минимуму ненужные операции упреждающего чтения, установите для блочного устройства Linux параметр упреждающего чтения 8 КБ. (См. раздел Рекомендуемые параметры рабочей среды в документации DataStax.)
Установите значение упреждающего чтения 8 КБ для всех блочных устройств в чередующемся наборе и на самом матричном устройстве (например, /dev/md0).
Дополнительные сведения см. в разделе Сравнение влияния параметров упреждающего чтения диска (GitHub).
Размер фрагмента дискового массива mdadm
При запуске Cassandra в Azure обычно создается чередующийся набор mdadm (т. е. RAID 0) из нескольких дисков данных, чтобы увеличить общую пропускную способность диска и число операций ввода-вывода в секунду ближе к ограничениям виртуальной машины. Оптимальный размер блока чередования дисков — это параметр, зависящий от приложения. Например, для рабочих нагрузок SQL Server OLTP рекомендуется 64 КБ. Для рабочих нагрузок хранилища данных рекомендуется 256 КБ.
Наши тесты не выявили существенных различий между размерами блоков 64 КБ, 128 KБ и 256 КБ для рабочих нагрузок чтения Cassandra. Однако есть небольшое, едва различимое преимущество для размера блока 128 KБ. Таким образом, мы рекомендуем следующее.
Если вы уже используете размер блока 64 K или 256 K, это не имеет смысла перестроить массив дисков для использования размера 128-K.
В новой конфигурации имеет смысл использовать 128 КБ с самого начала.
Дополнительные сведения см. в разделе Измерение влияния размера фрагментов mdadm на производительность Cassandra (GitHub).
Файловая система журнала фиксации
Операции записи Cassandra выполняются лучше всего, если журналы фиксации находятся на дисках с высокой пропускной способностью и низкой задержкой. В конфигурации по умолчанию Cassandra 3. x сбрасывает данные из памяти в файл журнала фиксации каждые 10 секунд и не обращается к диску при каждой записи. В этой конфигурации производительность записи практически идентична независимо от того, находится ли журнал фиксации на подключенных дисках уровня "Премиум" или на локальных/временных дисках.
Журналы фиксации должны быть устойчивыми, чтобы перезапущенный узел мог воссоздать все данные, еще не находящиеся в файлах данных, из очищенных журналов фиксации. Для повышения устойчивости храните журналы фиксации на управляемых дисках уровня "Премиум", а не в локальном хранилище, которое может быть потеряно при переносе виртуальной машины на другой узел.
Согласно нашим тестам, Cassandra в CentOS 7.x может иметь более низкую производительность записи, если журналы фиксации находятся в файловой системе xfs, а не в ext4. Включение сжатия журнала фиксации приводит производительность xfs в соответствие с ext4. В наших тестах сжатая xfs работала так же хорошо, как сжатая и несжатая ext4.
Дополнительные сведения см. в разделе Наблюдения над файловыми системами ext4 и xfs, а также сжатыми журналами фиксации (GitHub).
Измерение базовой производительности виртуальной машины
После развертывания виртуальных машин для Cassandra Ring выполните несколько искусственных тестов, чтобы установить базовые показатели производительности сети и диска. При помощи этих тестов удостоверьтесь, что производительность соответствует ожидаемым показателям, основанным на размере виртуальной машины.
Позже, когда вы запустите фактическую рабочую нагрузку, знание базовых показателей производительности поможет определять потенциальные узкие места. Например, знание базового уровня производительности для исходящего сетевого трафика на виртуальной машине может помочь исключить сеть в качестве узкого места.
Дополнительные сведения о выполнении тестов производительности см. в статье Проверка базовых показателей производительности виртуальной машины Azure (GitHub).
Размер документа
Производительность чтения и записи Cassandra зависит от размера документа. При чтении или записи документов большего размера можно ожидать более высокую задержку и меньшее количество операций в секунду.
Дополнительные сведения см. в разделе Сравнение относительной производительности различных размеров документов Cassandra (GitHub).
Коэффициент репликации
В большинстве рабочих нагрузок Cassandra используется коэффициент репликации (RF), равный 3 при использовании подключенных дисков уровня "Премиум" и даже 5 при использовании временных локальных дисков. Количество узлов в Cassandra Ring должно быть кратным коэффициенту репликации. Например, RF, равный 3, подразумевает кольцо из 3, 6, 9 или 12 узлов, а RF, равный 5 — из 5, 10, 15 или 20 узлов. При использовании RF больше 1 и уровня согласованности LOCAL_QUORUM производительность операций чтения и записи обычно ниже, чем при той же рабочей нагрузке, выполняемой с RF, равным 1.
Дополнительные сведения см. в разделе Сравнение относительной производительности различных коэффициентов репликации (GitHub).
Кэширование страниц в Linux
Когда код Java Cassandra считывает файлы данных, он использует обычные операции ввода-вывода и преимущества кэширования страниц Linux. После однократного чтения частей файла прочитанное содержимое сохраняется в кэше страниц ОС. Последующий доступ на чтение к тем же данным предоставляется гораздо быстрее.
По этой причине при выполнении тестов производительности чтения для одних и тех же данных вторая и последующие операции чтения будут выполняться намного быстрее, чем исходная операция чтения, которая требовала доступа к данным на удаленном диске данных или в кэше узла, если включен режим только для чтения. Чтобы получить аналогичные показатели производительности при последующих запусках, очистите кэш страниц в Linux и перезапустите службу Cassandra, чтобы очистить ее внутреннюю память. Если кэширование только для чтения включено, данные могут находиться в кэше узла, и последующие операции чтения будут выполняться быстрее даже после очистки кэша страниц ОС и перезапуска службы Cassandra.
Дополнительные сведения см. в статье Наблюдения за использованием Cassandra кэширования страниц в Linux (GitHub).
Репликация между несколькими центрами обработки данных
Cassandra изначально поддерживает концепцию нескольких центров обработки данных, что упрощает настройку одного кольца Cassandra в нескольких регионах Azure или между зонами доступности в одном регионе.
Для развертывания в нескольких регионах используйте глобальный пиринг виртуальной сети Azure, чтобы подключить виртуальные сети в разных регионах. Когда виртуальные машины развернуты в одном регионе, но в разных зонах доступности, они могут находиться в одной виртуальной сети.
Важно измерить базовый показатель задержки при передаче данных между регионами. Задержка в сети между регионами может быть в 10–100 раз выше, чем задержка в пределах региона. Ожидайте задержку появления данных во втором регионе при использовании согласованности записи LOCAL_QUORUM или значительное снижение производительности записи при использовании EACH_QUORUM.
При запуске Apache Cassandra в большом масштабе и в среде с несколькими контроллерами домена восстановление узлов становится сложной задачей. Такие средства, как Reaper , могут помочь координировать восстановление в масштабе (например, по всем узлам в центре обработки данных, одному центру обработки данных за раз, чтобы ограничить нагрузку во всем кластере). Однако восстановление узлов для крупных кластеров еще не полностью решено и применяется во всех средах, будь то локальная или облачная среда.
При добавлении узлов в дополнительный регион производительность не масштабируется линейно, так как некоторые ресурсы пропускной способности и ЦП или диска тратятся на получение и отправку трафика репликации в разных регионах.
Дополнительные сведения см. в разделе Измерение влияния репликации с несколькими контроллерами домена между регионами (GitHub).
Конфигурация механизма направленной отправки
В Cassandra Ring с несколькими регионами рабочие нагрузки записи с уровнем согласованности LOCAL_QUORUM могут потерять данные в дополнительном регионе. По умолчанию механизм направленной отправки Cassandra регулируется до относительно низкой максимальной пропускной способности и временем существования подсказки в три часа. Для рабочих нагрузок с большим количеством операций записи рекомендуется увеличить намеченное время регулирования и периода подсказки, чтобы убедиться, что намеки не удаляются до их репликации.
Дополнительную информацию см. в разделе Наблюдения за механизмом направленной отправки при репликации между регионами (GitHub).
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Арсен Владимирский | Главный инженер клиента
Другой участник:
- Тео ван Краей | Старший менеджер по программам
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Дополнительные сведения об этих результатах производительности см. в статье Эксперименты производительности Cassandra на виртуальных машинах Azure.
Сведения об общих параметрах Cassandra, не относящихся к Azure, см. в следующих статьях.