Я изучаю, как реализовать репликацию в режиме, близком к реальному времени, из основного центра обработки данных на сайт аварийного восстановления. Данные, которые будут реплицированы, будут:
Для простоты предположим, что это всего менее 10 ТБ данных со средней скоростью записи менее 100 МБ / с, максимальной скоростью 1500 МБ / с, а канал между основным и резервным центрами обработки данных будет иметь пропускную способность 10 ГБ / с.
Асинхронная репликация приемлема и желательна - в случае прерывистой записи или короткого отключения связи между обоими центрами обработки данных - мы не хотим снижать скорость локальной записи и готовы пожертвовать самой последней частью данных, которая может быть потеряна в случае катастрофического отказа основного центра обработки данных.
Насколько я понимаю, мы можем выбирать между:
Есть ли другие решения, которые стоит рассмотреть?
Спасибо!
Для БД и зависимых от БД приложений их проприетарная репликация всегда предпочтительнее "общей" блочной репликации по многим причинам, одна из которых - согласованность БД. Поэтому используйте группы доступности SQL Server (AG), доступные с некоторыми ограничениями, даже со стандартной версией SQL Server с 2014 или 2015 года, используйте MS Exchange DAG, SAP HANA, реплики AeroSpike и т. Д. Я бы не стал делать DRBD в 2020 году, потому что это скорее низкая производительность ввода-вывода, особенно с конфигурациями all-flash, DRBD явно предназначен для вращающихся дисков и сетей без RDMA с высокой задержкой еще в начале 2000-х годов и чрезвычайно плохой защитой от проблем с разделением мозга. Технология Virtual SAN, которую вы можете найти в составе основных гипервизоров, является еще одним хорошим вариантом встроенной технологии репликации DB.
Вы можете рассмотреть геореплицируемые SDS-решения, такие как Gluster и Ceph, использовать репликацию ZFS или LVM.
Для KVM в qemu теперь есть функция CDC, и создаются различные решения для потоковой передачи измененных блоков по сетевому каналу без репликации всего базового блочного устройства.
Для любого другого программного обеспечения (вы упомянули базы данных) действительно лучший подход - использовать собственные инструменты, которые может предоставить ваша база данных. Многие современные базы данных NoSQL не требуют наличия мастера и могут просто работать в режиме с несколькими контроллерами домена, с репликами, размещенными на каждом контроллере домена или стойке.