The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21, opennews (??), 09-Окт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


47. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +1 +/
Сообщение от Tron is Whistling (?), 09-Окт-23, 21:16 
> - автоматизации по кластеризации нет

Автоматизация лепится самостоятельно. У меня её тоже нет - оно прекрасно ворочается на ocfs2 с haproxy в качестве LB.

> - полнотекстового поиска нет

Есть.

> - логики архивации и очистки с возможностью поставить на удержание

Делается совершенно другими способами.

> 3) И Zimbra мне еще тут вспомнили, которая не выдержав конкуренции закрылась
> (в смысле код)

Чичиго? Нет только бинарей, а так - бери, собирай.

В целом кто тут не в теме - понятно прекрасно.

> Ей богу, проще поставить Exchange + SharePoint + Office Online Server у

И давно вы на этом MSP для хотя бы одной сотни тысяч клиентов собирали? Сколько нод было в кластере?

Ответить | Правка | Наверх | Cообщить модератору

54. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (40), 09-Окт-23, 23:49 
> И давно вы на этом MSP для хотя бы одной сотни тысяч клиентов собирали? Сколько нод было в кластере?

А в чем проблема? Там простая и незатейливая архитектура:
1. 2-16 MTA между PoD-ами с антиспамами
2. 2-16 фронтенд-серверов не содержащих почтовые ящики для "рендеринга" сервисов (бывшая CAS-роль, сейчас они совмещены) на каждый PoD SMTP на них тоже проксируется
4. Всё это смотрит на группу кластеров-полок (хочешь хоть 1000 поставь, 1000 кластеров, а не серверов в кластере), каждый из которых смотрит на домен отказоустойчивости и представлен в форме DAG в режиме Active-Passive между двумя датацентрами.
5. В каждой DAG у тебя количество серверов зависит от количества баз на одном медленном диске, если ты используешь стороннее резервное копирование или количество баз +1, если стандартное (это требование к топологии DR для большого развертывания Exchange)
6. Требуется DCI между всеми датацентрами на L3
7. Балансировщики нагрузки работают на прицепляя адреса VIP с учетом BGP и ECMP, а не на VRRP.
8. Топология расширяет регион не по одному датацентру, а парами, потому что так устроено развертывание Exchange.
Именно так устроены регионы Microsoft 365, только они используют ARR, я предпочитаю HAproxy. Это все не секрет. Там есть пара тонкостей с логином и поддержкой OAuth2, которая полноценно ожидается в следующей версии, сейчас это делается проксяками IMAP/POP3, которые либо прориетарные рядом с антиспам-решением. В слудеющей версии обещали нативную поддержку.

Я к тому, что если ты чего-то не делал и не знаешь, не значит что этого нет.

Когда я последний раз видел dovecot - это был огрызок сервиса, что ты и подтверждаешь вот этим:
> Автоматизация лепится самостоятельно. У меня её тоже нет - оно прекрасно ворочается на ocfs2 с haproxy в качестве LB.

Ну то есть вместо того чтобы корректно реплицировать почту по объектному хранилищу (или ISAM-базам как в Exchange) ты делаешь либо inverted pyramid of doom, закидывая на LUN на внешний сервер хранения, который падает и становится неконсистентным даже когда двухголовый с нативной поддержкой открытого стандарта Storage Bridge Bay, либо ты всё же делаешь репликацию и тогда ты потерял кучу дисков впустую на хранения тонны ненужных реплик ради защиты RAID-совместимых хранилок, либо ты цепляешь LUN с Object Storage, что тоже даёт перерасход по дискам на большом развертывании, если у тебя нет Application Aware репликации.
И как ты свой кластер уже раскидал на 2 датацентра? А 4 уже занял? Пффф...

>> - полнотекстового поиска нет
>Есть.

Нет. Ты хочешь сказать, что в бесплатной версии dovecot есть полнотекстовый поиск? С каких это пор?
Технически к его базам можно прикрутить Apache Solr, и ты внедрил её на 100 000 пользователей? Это нетривиальная задача, учитывая, что шарды Solr потенциально будут размером с половину базы потребуют невменяемое количество RAM и должны быть установлены рядом на соседних серверах, потому что это полнотекстовый поиск общего назначения в первую очередь для НСИ-приложений. Нет там своего полнотекстового поиска. Только в платной версии.

>> - логики архивации и очистки с возможностью поставить на удержание
> Делается совершенно другими способами.

Почта сервис, который запрашивается полицией и судом в случае разбирательства. Так во всём мире.
Каждый почтовый сервис, особенно провайдерский, должен иметь возможность отключить удаление элементов в ящике, отключить очистку старых удаленных элементов из ящика по запросу организации выдавшей ордер. Какими средствами собрался это делать? Тюнить расписание бекапов? Пересылать всю входящую и исходящую почту куда-то еще внешними правилами? Теоретик, ты.

> Чичиго? Нет только бинарей, а так - бери, собирай.

Ах, да действительно. Они в очередной раз поменяли свою точку зрения, ну да ладно, я перестал уже следить.
Они ведь сначала сказали, что вообще 9-ка будет полностью закрытая. Они кинули с этими выкрутасами кучу партнеров, которые делали для них плагины и предоставляли продукты для провайдеров с этим решением Zimbra 9 совершила харакири на рынке сервиспровайдеров и мертва. Сейчас они предлагают купить специальную мультитеннантную версию Network Edition для как они называют BSP, которая идёт совместно с NextCloud (лицензии брать отдельно) и другими партнёрскими продуктами. Они просто посчитали, что другие, кто делал альтернативные решения для провайдеров нужно кинуть и тем самым в очередной раз испортили себе репутацию.
Видимо, чтобы вернуть фарш назад снова приоткрыли код, чтобы сообщить, что всё не так плохо... Как бы их open source edition и раньше был убог, а в условиях отсутствия Desktop-версии и поддержки MAPI и ActiveSync и Push (только в проприетарной) - это все даром не надо, да и за деньги не продадут.

> В целом кто тут не в теме - понятно прекрасно.

Вот ты похож на админа-придурка с которыми мне приходилось общаться про "чудесные" решения для почты, которые не выдерживают никакой критики когда у тебя много серверов и надо сделать так чтобы оно работало под SLA 98%+ и так чтобы не нужно было в случае падения хранилок восстанавливать сторадж на несколько петабайт разом, пока клиенты ждут.

Exchange в РФ стал абсолютно безальтернативен, кстати. Это единственный продукт, который можно полностью скоммуниздить, который не проверяет лицензии настолько, что у людей в Android-е Push работает и который держит огромные объемы, если следовать принципам его развертывания, которые описаны в документации, которая еще и вся открытая и доступная. А все эти (при)открытые продукты, нужно покупать, если нужно сделать что-то серьёзное.

P.S. Установку SP и OOS я тебе расписывать не буду, но там несколько иные подходы в проектировании да и лень, ты все равно не поймешь. У тебя зимбра с давкотом работают.

Ответить | Правка | Наверх | Cообщить модератору

60. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (28), 10-Окт-23, 01:09 
> А в чем проблема? Там простая и незатейливая архитектура:

Слоник в домене? Ты ли это?)

Ответить | Правка | Наверх | Cообщить модератору

61. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (28), 10-Окт-23, 01:15 
Да. Ты сделал мой вечер. Капитанить над Dovecot vs Microsoft 365 это как надо упороться?. Ты еще встань для важности:).
Ответить | Правка | Наверх | Cообщить модератору

67. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Tron is Whistling (?), 10-Окт-23, 07:37 
>> И давно вы на этом MSP для хотя бы одной сотни тысяч клиентов собирали? Сколько нод было в кластере?
> домен отказоустойчивости и представлен в форме DAG в режиме Active-Passive между

Active-Passive? Давай, до свидания.
Более того, правильно отметил: оно упрётся в скорость самой медленной ноды.

> либо ты всё же делаешь репликацию и тогда ты потерял кучу дисков впустую на хранения тонны ненужных реплик

Active-Passive ноды диски впустую не теряют, ога.

> И как ты свой кластер уже раскидал на 2 датацентра? А 4 уже занял?

На 3. Ибо кластер.

> Нет. Ты хочешь сказать, что в бесплатной версии dovecot есть полнотекстовый поиск?
> С каких это пор?

Обычный эмбедный Lucene. Не менее 10 лет уже.

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

Всё проще: копия проходящей почты ровно на 1 год, положенный законом. Журнал.
И не надо никаких извращений с самой почтовой базой.

Забивать гвозди экскаватором - это не моё, да.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

69. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Tron is Whistling (?), 10-Окт-23, 07:39 
Забыл добавить.

Active-Passive ноды с костылём в виде тормознющей репликации ISAM, которая благополучно теряет всю очередь при малейшем некорректном завершении, а при малейшем аппаратном сбое ложится целиком без шансов на быстрое восстановление. Нет, можно и одну DB на пользователя нагородить, но тогда оно потребует терабайты дорогой оперативки.

Ответить | Правка | Наверх | Cообщить модератору

77. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (40), 10-Окт-23, 13:05 
Ты понимаешь, что когда мы говорим про ISAM мы говорим про реализацию Extensible Storage Engine, а не про те недоразумения, которые были в Linux типа myISAM или Aria. ESE это ISAM-сторадж c поддержкой атомарности, транзакционности, WAL, репликацией и прочее. На нем держится вся Azure / Office 365, на нем работает Azure AD, Exchange Online и прочее, а тебя фантазии про медленность репликации проблемы с восстановлением.
Речь об этом: https://github.com/microsoft/Extensible-Storage-Engine

Я прекрасно понимаю, что всё что ты написал справедливо для реализации ISAM в бесплатных базульках в Linux, но у него есть и нормальные реализации.

Ответить | Правка | Наверх | Cообщить модератору

80. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Tron is Whistling (?), 10-Окт-23, 14:48 
> Я прекрасно понимаю, что всё что ты написал справедливо для реализации ISAM
> в бесплатных базульках в Linux, но у него есть и нормальные
> реализации.

Там проблема в другом. Проблема в том, что для почтовой хранилки это не очень пригодно. Dovecot'овский mdbox по сравнению с ней выглядит верхом совершенства. Active-passive репликация - в рамках почтового сервиса абсолютно бессмысленное решение, делается 1000+1 других способов.

Ответить | Правка | Наверх | Cообщить модератору

93. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (40), 10-Окт-23, 22:51 
> Проблема в том, что для почтовой хранилки это не очень пригодно.

То есть весь Office 365 это использует, а тебе не пригодно. Это не просто пригодно, но и проверено огромными облачными нагрузками.

> Active-passive репликация - в рамках почтового сервиса абсолютно бессмысленное решение, делается 1000+1 других способов.

Ну перечисли мне хотя бы первые 4 из этих "1000+1 других способов". Эта репликация в Exchange используется категорически вместо блочной репликации стораджа. На базе ESE поднимается специально оформленный объектный сторадж. Еще и с поддержкой полнотекстового поиска из коробки. Теперь их там 2 кстати.

Или ты всерьёз предполагаешь что кто-то использует не просто active-active кластеризацию сервисов, а прямо master-master на сторадже на крупных развертываниях? Мастер-мастер именно для журналов транзакций, БД и прочего всего - крайне редкий зверь для мелких задач, а ты про почту с её петабайтами объемов.

В общем есть 2 стула^W вопроса про чистый master-master для данных (пусть даже без блочных ухищрений, прямо на обычных дисках):
- Ты либо используешь синхронную репликацию и ждёшь коммита в лог на всех узлах кластера. Dovecot, опять же использовал её для сервисной части конфигурации в БД, через Galera Cluster. Редкая помойка, но работает, если там нет самих писем и они в другом месте.
- Либо ты используешь асинхронную репликацию на master-master и тогда сплитбрейн гарантирует потерю данных в случае неверного промоутинга. И выйти из него задача нетривиальная.

Просто покрутив много лет назад, когда это было всем таким модным Galera Cluster, MariaDB и свежие версии MySQL для веб-соплекух c асинхронным master-master, выкинул это как ненужное усложнение, которое не понятно какую проблему решает. Да, для пары тройки локаций это работает, но если у тебя сотни физических почтовых серверов...

Ответить | Правка | Наверх | Cообщить модератору

94. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Tron is Whistling (?), 10-Окт-23, 23:13 
> Или ты всерьёз предполагаешь что кто-то использует не просто active-active кластеризацию сервисов, а прямо master-master на сторадже на крупных развертываниях? Мастер-мастер именно для журналов транзакций, БД и прочего всего - крайне редкий зверь для мелких задач, а ты про почту с её петабайтами объемов.

Именно поэтому для почтовой хранилки "классические БД" по факту и непригодны. Либо object storage, либо что-то ещё кластеризуемое, третьего не дано. Весь этот эксченджевский EDB - лютый костыль за неимением лучшего, слепили из того что было.

> Ты либо используешь синхронную репликацию и ждёшь коммита в лог на всех узлах кластера.

Или ты не используешь БД для хранения почты.

Ответить | Правка | Наверх | Cообщить модератору

97. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (40), 11-Окт-23, 03:25 
> Либо object storage, либо что-то ещё кластеризуемое, третьего не дано.

А что это по твоему и что ты считаешь за object storage?

Object Storage это понятие растяжимое. Да у тебя там есть шарды, они как-то реплицируются и имеют какую-то избыточность по какому-то принципу.

Одни пихают ФС поверх object storage. Само по себе решает только проблему inverted pyramid of doom, автоматизируя репликацию стораджа между узлами кластера с JBOD. Такой вариант не подходит для почты.

Вторые используют его для объектов похожим образом как делают ключ-значение. Я к тому, что движок этого object storage тебе надо было бы определить, потому что они все разные. Вся эта нестандартизированная терминология в конечном итоге сводится к тому что есть документо-ориентированная база данных, no-SQL, хранилище ключ-значение или object storage и под капотом какая-то логика хранения этого всего. Учитывая сколько там решений и путаницы в определениях, то продукты по таким категориям делить - дело не благодарное.

И самое главное, каждый пытается изобрести свою документо-ориентированную базу со своим способом кластеризации и со своей внутренней логикой репликации по JBOD-узлам. Так который object storage ты видишь идеальным для почты и чем конкретно на эту роль не подходит ESE, который выполняет эту работу блин 30 лет и создан для хранения именно объектов, а не классического OLTP с SQL.

> эксченджевский EDB - лютый костыль за неимением лучшего

А в чем его костыльность конкретно выражается? Ты можешь его взять и прикрутить к своей соплекухе и поверх него построить документо-ориентированную БД с блобами средней жирности. Хочешь, объекты в нем храни. Это же низкоуровневая штука.

Причем подобрать себе сторадж под письма, которые по определению документы - это полбеды. Тебе нужно его еще забекапить, восстановить, восстановить только определенные объекты, обслуживать по вопросам очистки старых данных и искать по нему полнотекстовым поиском. И вот ESE это всё умеет. И нагрузку он держит такую что весь Exchange Online на нем. И утилит и бекапов готовых куча. В чем проблема, то?

Ответить | Правка | Наверх | Cообщить модератору

76. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (40), 10-Окт-23, 12:59 
> Active-Passive? Давай, до свидания.

Active-Passive это балансировка подключения клиентов между двумя датацентрами, ты видимо не понимаешь логику развертывания от слова "совсем". Есть несколько топологий подключения пользователей. В зависимости от конфигурации сервисов Autodiscover у тебя либо все пользователи определенного кластера "любят" первый ДЦ и переключаются на второй при полном сбое датацентра, а другие пользователи живущие на другом кластере наоборот. Это Active-Passive. Сделана привязка пользователь к кластеру. Альтернативный вариант подключения Active-Active, когда каждому пользователю поставлен в соответствие сайт AD, тогда кластер симметричен в каждом ДЦ. В случае Active-Passive он асимметричен.

> Active-Passive ноды диски впустую не теряют, ога.

Как я и сказал, ты не понимаешь логику крупного развертывания Exchange и споришь по-глупости. Exchange сам держит свой Storage равно как и dovecot в платной версии. Он управляет логикой репликации по дискам без применения RAID-ов. Ставится на сервер с кучей дисков и слабым процом, который за Mailbox-роли занимается только репликацией стораджей ESE.

Обычно люди ставят базы поверх RAID с каким-то зеркалом 1 или 10, потому что 5 и 6 неимоверно долго перестраиваются. Exchange поддерживает такое развертывание, но категорически его не рекомендует, потому что это не даёт никакой ценности ни по восстановлению, ни по управлению ни по отказоустойчивости.

Вот тебе простой пример если я ставлю базу почты на RAID10 в кластере с двумя узлами, то у меня 4 копии этой базы. Если я поставлю её на рекомендуемое развертывние, то у меня будет 3 узла Exchange и 3 копии этой базы. И если режим Active-Passive для междатацентрового Disaster Recovery, то 4 ноды, 3 в одном ДЦ, и одна во втором. Если резервное копирование глупое и не понимает eDiscovery и DAG, то нужно 5 нод. 3 в одном ДЦ, четвертая полоноценная во втором и третья lagged-копия тоже втором с задержкой репликации на 1-7 дней, которая нужна в случае полного развала кластера с порчей данных в условиях, когда система резервного копирования глупа и может восстановить только данные, но не кластер целиком (отсутствует поддержка Application Aware Backup).

В Active-Active кластеры в обоих ДЦ будут симметричными, но обычно этот режим применяется в корпоративной среде, а не в провайдерской. В провайдерской у тебя один кластер 3+1, второй 1+3 и так этих кластеров, пока все стойки не позанимаешь.

> На 3. Ибо кластер.

Я не понимаю почему 3, могу только догадаться. В UNIX-подобных ОС редко встречается понятие кластерного свидетеля, то есть обычно для достижения кворума требуется нечетное количество ПОЛНОЦЕННЫХ узлов, потому что свидетели всегда специфичны для приложений и их редко делают. Просто напоминаю тебе что Exchange это всегда гиперкластер (кластер кластеров) причем внутри каждого кластера узлы слабо связаны друг сдругом и повторяют специфику сетевой топологии. Оно растянуто двух кластеров между двумя ДЦ с двумя свидетелями. Ограничение в 3 и в нечетнотность это очередные ограничения твоих продуктов.

Но если ты собрался раскинуть 3 узла ОБЫЧНОГО кластера на 3 ДЦ, я рекомендую тебе уйти из профессии и не админить ничего больше никогда. Кластерный Heartbeat не должен зависить от транспортной между датацентрами. При растягивании обычного кластера и при нарушении роутинга между ДЦ он у тебя так развалится, что тебе придётся все восстанавливать по очереди и пересобирать с передобавлением нод и вытягиванием реплик... опять же если ты используешь репликацию...

А если ты используешь репликацию, как это часто делают поверх локальных RAID в каждом узле и у тебя 3 узла, то одна копия у тебя хранится 6 раз. Если же у тебя внешний LUN для кластерного стораджа и ты цепляешь его сквозь транспортную сеть между 3 датацентрами... то так делать нельзя. Даже если ты подашь L1 через DWDM то это всё до первого серьезного сбоя и тогда тебе конец.

> Обычный эмбедный Lucene. Не менее 10 лет уже.

Мне казалось его и сделали платным, разве нет? Ну то есть полнотекстовый поиск они сами себе затюнили как надо, а другие пусть ковыряются сами.

> Всё проще: копия проходящей почты ровно на 1 год, положенный законом. Журнал.

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

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

81. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Tron is Whistling (?), 10-Окт-23, 15:08 
>> Active-Passive? Давай, до свидания.
> Active-Passive это балансировка подключения клиентов между двумя датацентрами.

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

> Вот тебе простой пример если я ставлю базу почты на RAID10

На этом месте можно дальше уже и не обсуждать.

Понимаешь в чём дело, у меня сейчас ровно 4 копии данных - если RAID считать. На 3 DC.

> Я не понимаю почему 3, могу только догадаться

Потому что кворум. Линковый меш из трёх DC, с дуальными линками идущими разными путями.
Полный синхронный active-active-active. Любая нода может в любой момент принять любого пользователя.

> Кластерный Heartbeat не должен зависить от транспортной между датацентрами

Через астрал делаете?
Всё просто: развал линков != развал DC. В случае полного отвала одного DC остаётся кворум из двух.
Но это не мешает параллельно жить внешней арбитрации с 4 точки "внешнего мира", просто она немножко по-другому реализована - все 3 DC смотрят в эту самую арбитрацию как дополнительный источник данных о том, кто жив, когда нужно решение по кворуму.

> При нарушении роутинга между ДЦ он у тебя так развалится

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

> Если же у тебя внешний LUN для кластерного стораджа и ты цепляешь его сквозь транспортную сеть между 3 датацентрами

С этого момента поподробнее. В чём заключается конец? Один из сторейджей всегда write master. В случае совсем серьёзного сбоя останавливаются все ноды, которые не рядом с write master, они просто не могут произвести запись и вылетают из кластера. Здесь как раз именно оптимально цеплять LUN ровно там, где у тебя сами ноды пропущены, потому что тогда они потеряют кворум чуть раньше, чем обнаружат, что у них с записью полная задница.

> Мне казалось его и сделали платным, разве нет?

Нет.

> Ясно, через бекапы

Чтэ? Какие бэкапы? Какие сутки? Обычный (ну, ладно, не совсем обычный - дедуплицированный на входе) журнал, в который банально кладется копия проходящих сообщений - принятых/отправленных, либо положенных через IMAP. Ровно в момент прихода.

Ответить | Правка | Наверх | Cообщить модератору

92. "Новая версия POP3 и IMAP4 сервера Dovecot 2.3.21"  +/
Сообщение от Аноним (40), 10-Окт-23, 22:07 
Давай-ка ты себя послушаешь сам.

Сначала ты пишешь:
> У меня же 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.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру