Лучшая практика настройки cassandra на ec2 с большим объемом данных

Я делаю большую миграцию с физических машин на экземпляры ec2.

В настоящее время у меня есть 3 узла x.large, каждый из которых имеет 4 накопителя хранилища экземпляров (raid-0 1.6TB). После того, как я это установил, я вспомнил, что "данные об объеме хранилища экземпляра сохраняются только в течение жизни связанного с ним экземпляра Amazon EC2, а если вы остановите или завершите экземпляр, все данные на томах хранилища экземпляров будут потеряны".

Что люди обычно делают в этой ситуации? Я беспокоюсь, что если один из ящиков упадет, тогда все данные будут потеряны в этом поле, если он не будет на 100% реплицироваться на другом.

http://www.hulen.com/?p=326 Я прочитал в приведенной выше ссылке, что эти ребята используют ephermal диски и периодически резервируют содержимое с помощью EBS-дисков и снимков ".

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

Ответы

Ответ 1

Я работаю Cassandra на EC2 более 2 лет. Чтобы решить ваши проблемы, вам необходимо создать надлежащую архитектуру доступности на EC2 для вашего кластера Cassandra. Вот вам список пулей:

Рассмотрим как минимум 3 зоны для настройки вашего кластера;
Используйте NetworkTopologyStrategy с EC2Snitch/EC2MultiRegionSnitch для распространения реплики ваших данных в каждую зону; это означает, что машины в каждой зоне будут объединены в ваш полный набор данных; например, strategy_options будет похож на {us-east: 3}.

Вышеуказанные два совета должны удовлетворять базовой доступности в AWS, и если ваши запросы будут отправлены с использованием LOCAL_QUORUM, ваше приложение будет в порядке, даже если одна зона опустится.

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

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

Об EBS vs Ephemeral:

Я всегда был против использования томов EBS во всех продуктах, потому что это одна из худших услуг AWS с точки зрения доступности. Они спускаются несколько раз в год, и их недостаток обычно каскадирует к другим услугам AWS, таким как ELB и RDS. Они также похожи на подключенное сетевое хранилище, поэтому любое чтение/запись должно проходить через сеть. Не используйте их. Даже DataStax не рекомендует их:

http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/architecture/../../cassandra/architecture/architecturePlanningEC2_c.html

О резервном копировании:

Я использую решение под названием Priam (https://github.com/Netflix/Priam), которое было написано Netflix. Это может сделать ночной снимок вашего кластера и скопировать все на S3. Если вы включите incremental_backups, он также загрузит инкрементные резервные копии на S3. В случае снижения node вы можете вызвать восстановление на конкретном node с помощью простого вызова API. Он восстанавливается намного быстрее и не накладывает много потоковой нагрузки на другие узлы. Я также добавил патч к нему, который позволяет вам придумывать такие вещи, как создание нескольких контроллеров домена внутри одной области AWS.

Вы можете прочитать о моей настройке здесь: http://aryanet.com/blog/shrinking-the-cassandra-cluster-to-fewer-nodes

Надежда выше помогает.

Ответ 2

Это действительно зависит от ваших данных. Но сначала вы должны учитывать, что у Cassandra есть свой механизм резервного копирования/репликации. Если один из ваших узлов опустится, остальные узлы все равно будут иметь ваши данные. Чем выше ваш коэффициент репликации, тем "безопаснее" будут ваши данные, а также тем выше коэффициент репликации, чем больше узлов Cassandra вам понадобится.

Если ваши данные очень важны, вы должны спросить себя, можете ли вы эффективно перестроить свои данные без необходимости резервного копирования в эфемерном хранилище? Вы ищете лучшую производительность? Эфемерное хранилище работает намного лучше, чем EBS, и это будет отлично работать, если ваше приложение будет интенсивно читать/писать. В нашем случае мы использовали Cassandra с эфемерным хранилищем, заполненным данными, которые мы уже хранили в Amazon S3.

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

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

Здесь еще одно обсуждение о Ephemeral vs EBS:

Как взять резервную копию экземпляра aws ec2 экземпляра/эфемерного хранилища?

Надеюсь, что это поможет.