Давай-ка ты себя послушаешь сам.

Сначала ты пишешь:
> У меня же active-active между тремя DC. С отдельной "базой" на каждого пользователя, что сильно упрощает менеджу и шардинг всего этого хозяйства.

Потом ты пишешь:
> Один из сторейджей всегда write master.

То есть active-active у тебя на почтовом кластере по работе с базами и на доступе, а storage, на котором у тебя базы как традиционный LUN на RAID c четырьмя копиями каждой базы. Я правильно понимаю?

Этот кластерный Storage у тебя в режиме Active-Active на запись? Ежели да, то скажи название продукта :-)
Если это обычный LUN пришедший по iSCSI или FC или локальный RAID, то у тебя на запись только одна точка. Что приводит меня в недоумение... Какого черта ты мне кичишься что у тебя базы в Active-Active тогда, если запись у тебя всё равно в одну точку. В чем тогда принципиальная разница от Exchange?

> Давай винду пропустим мимо, там половина терминов извращена, от слова "совсем".

Нет не пропустим, потому что пока не поймем отличия в наименованиях не поймем друг друга.

Например, если мы считаем за active-active возможность сделать так, что каждый сервер может обслужить и принять любого пользователя, то тогда у меня абсолютно все сервера по всем протоколам могут в Exchange обслужить любого пользователя. Любой кластер может принять от пользователя запрос на вебсервисы, рисование вебморд, POP/IMAP и SMTP. Принять и отправить почту. База может даже лежать на соседнем DAG в соседнем кластере или датацентре - это не проблема. DAG организует только сторадж и больше ничего. Сервисы все Active-Active, только сторадж часть всегда имеет одну копию в которую можно писать.

Да, каждая база в DAG может быть активной на запись только на одной ноде, равно как и требования к блочному стораджу, который активен на запись только в одном месте. И что в этом такого?
На кластерах DAG лежат много баз. На каждом сервере много дисков. Эти диски не в RAID. На каждом диске 3 или более баз в зависимости от конфигурации сервера по дискам и от разверов одного DAG. На каждом узле DAG есть группа баз в активном режиме, а несколько в пассивном. Даже если у меня 4, 5 хоть 10 серверов в кластере у меня каждая отдельная база имеет только 3+1 копии в кластере DAG. 3 копии в одном датацентре и еще одна во втором датацентре, потому что каждый DAG растягивается на 2 ДЦ.

При этом репликацией объектов занимается Exchange, а не службы кластеризации. При этом я тоже могу каждому пользователю выдать по базе, но мне это не интересно, потому что я могу производить миграции с точностью до ящика между базами и наоборот использую их вместо RAID и других технологий блочного стораджа. С менеджингом этого вообще нет проблем, причем ни на каких объемах.

Давай-ка ты почитаешь: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/d...
И возможно поймешь, что я имею в виду.

> Всё просто: развал линков != развал DC. В случае полного отвала одного DC остаётся кворум из двух.

Если у тебя между датацентрами линки L1, и ты потерял 1 ДЦ, то всё нормально. Если у тебя есть транспортная сеть между большим количеством ДЦ, то есть вопросы роутинга. Транспортная сеть - это CLOS Network с использованием eBGP внутри и iBGP-на стыке с провайдерами. Это L3 Underlay поверх которого ты делаешь роутинг тунелей EVPN+MPLS или EVPN+VXLAN, что тебе удобнее. Развал BGP, который может произойти из-за человеческого фактора в этой ситуации приведет к сплитбрейну всех растянутых кластеров между несколькими датацентрами. И вот тогда начнется адище. А L1 решения не масштабируются, когда у тебя много локаций повсюду.

> В случае совсем серьёзного сбоя останавливаются все ноды, которые не рядом с write master, они просто не могут произвести запись и вылетают из кластера.

Вот это и есть адище, о котором я говорю. И от которого я защищен именно тем, что для каждого DAG есть 2 ДЦ. В каждом DAG сервера сгруппированы так чтобы данные были консистенты в рамках PoD и затем между PoD через еще один протокол решения сплитбрейнов.

> Да никак не развалится, потому что кроме внутреннего кворума есть ещё внешний арбитр.

С полным набором данных? Или это Cluster Witness? А почему он четвертый, этот арбитр? Или это просто внешний приемник для бекапов и мониторинга. Просто я такое даже не упоминаю нигде в своих текстах, потому что это как бы само собой предполагается. Инфраструктура мониторинга, бекапа и DR - это одно, а кластерный кворум - совсем другое. Но дело не в этом. Просто попрубуй сломать роутинг между ДЦ в лабораторных условиях и одновременно сделать IP-конфиликт. Поймешь что твое "никак не развалится" - это больше из области религии, а не технологии.

> журнал, в который банально кладется копия проходящих сообщений - принятых/отправленных, либо положенных через IMAP. Ровно в момент прихода.

Это для всех или только для тех на кого погоны попросили? Просто если для всех, то... ох блин, это же сколько надо места тогда впустую... А если ты можешь включить это только для некоторых ящиков, то это и есть Litigation Hold.