Назад | Перейти на главную страницу

Couchbase Enterprise 2.5: AWS, Rack Awareness и XDCR

В Couchbase Enterprise 2.5 входит функция Rack Awareness, которая предполагает, что данные реплик будут автоматически храниться в отдельных зонах доступности AWS без необходимости использования XDCR или дополнительной настройки.

Чем отличается репликация Rack Awareness от XDCR:

XDCR чем-то отличается, лучше по пропускной способности, по-разному сравнивает изменения, отличается ли протокол?

Что является лучшей практикой AWS:

RZA и XDCR предназначены для разных целей. RZA является частью внутрикластерной репликации в Couchbase, а XDCR - для межкластерной репликации.

Все, что делает RZA, - это хранит реплики vBuckets (шарды) кластера в другой группе серверов, чем там, где находятся его основные vBuckets. Это не происходит автоматически. Вы должны назначить группы серверов, переместить или создать узлы в этих группах, а затем перебалансировать кластер, чтобы перемещаться по vBuckets, а затем поддерживать этот список при перемещении узлов в кластер и из него с течением времени. Для нескольких зон AWS, скажем, у вас было шесть узлов в вашем кластере в US-West-2, например, по два узла в каждой зоне доступности. У вас будет три группы в Couchbase, по два узла в каждой группе, каждая группа представляет собой зону доступности. После перебалансировки соответствующие реплики vBuckets для активных vBuckets на узлах в группе 1 всегда будут в группах 2 или 3 и т. Д. Изображения в документации было бы неплохо сослаться здесь. http://docs.couchbase.com/admin/admin/Concepts/concept-rack-awareness.html Таким образом, RZA просто работает в сочетании со стандартной внутрикластерной репликацией Couchbase для обеспечения высокой доступности и отказоустойчивости.

С другой стороны, XDCR означает, что у вас есть два совершенно разных кластера, поэтому я сказал о межкластерной репликации. Таким образом, вы можете использовать XDCR для репликации из кластера A в регионе 1 в кластер B в регионе 2 для целей аварийного восстановления, однонаправленно или между каждым, двунаправленным. Вы можете запускать их активным / активным, с двунаправленной репликацией, но вы ДОЛЖНЫ четко осознавайте, как сегодня осуществляется разрешение конфликтов, и убедитесь, что вы программируете свое приложение с учетом этого, и убедитесь, что разрешение конфликтов соответствует вашему варианту использования. Это разрешение конфликтов - это то, над чем активно работают для расширения возможностей будущих версий Couchbase, но на сегодняшний день существует только один стиль разрешения конфликтов. Я также видел, как люди используют XDCR с обоими кластерами в одном регионе. Один из них - активный, другой - из чего создаются резервные копии, отчеты или что-то еще. Вы также можете использовать XDCR для интеграции с ElasticSearch или Solr, но это другое обсуждение. Наиболее частое использование XDCR, которое я видел, - это репликация аварийного восстановления между центрами обработки данных. Вам нужно будет купить корпоративную лицензию IMO, чтобы вы могли использовать зашифрованный XDCR, хотя и настроить свой AWS VPC, чтобы трафик правильно маршрутизировался между регионами. Затем, как и что-то в этом роде, следите, чтобы убедиться, что эти ссылки всегда активны, и т. Д. И т. Д., Но это не уникально для Couchbase.