none
Разнесение баз по сайтам в одной DAG группе. RRS feed

  • Общие обсуждения

  • Коллеги, приветствую!

    Появилась такая идея, продумываю ее теоретически, но не могу получить полную картину. 

    Центральный офис (site3) хранит в себе копии всех филиалов, все сервера в одной группе DAG. Пользователей филиалов не много. Подойдет ли такое решение, если бюджет на кол-во серверов сильно ограничен?

    13 октября 2014 г. 8:43

Все ответы

  • День добрый.

    Рекомендую реализовать на базе двух сайтов.

    Deploying high availability and site resilience


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.


    13 октября 2014 г. 8:48
    Модератор
  • День добрый.

    Рекомендую реализовать на базе двух сайтов.

    Deploying high availability and site resilience


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    Читал, но неудобно. У нас сильно разнесены офисы, хотелось бы держать подробную структуру в AD. Или же, сейчас это нормальная практика, что офис Сингапура и Канады в одном сайте? Я мог что-то упустить. 
    13 октября 2014 г. 9:00
  • Рекомендую делать по BPA, меньше неожиданностей потом будет.

    PS. Неудобно потом будет при отработке DR.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    13 октября 2014 г. 9:13
    Модератор
  • Олег, я интересуюсь, это и есть BP упразднять логическую структуру AD, site, site-links? Чего удастся избежать, соединив все сайты в два? По факту же, все равно в центральном офисе будут все копии, а на остальных активные. Ну просто хотелось бы услышать аргумент ЗА и ПРОТИВ, почему именно так?

    Ну например, меньше каких неожиданностей? 

    Что неудобного будет в отработке DR?

    Мне нужно собрать информацию для заказчика, нужно будет писать подробный документ, поэтому хотелось бы "уловить" направление, чтобы идти дальше самому :) 

     
    13 октября 2014 г. 9:41
  • В тестовой инфраструктуре разверните пару-тройку решений и отработайте для каждого варианта DR. Вот вам ЗА и ПРОТИВ кристализируется.

    PS. Информация не булькает. :)


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    13 октября 2014 г. 9:56
    Модератор
  • В тестовой легко, хотелось бы наверняка знать что именно тестировать. Я может бы и хотел конспект с Вас содрать, но на самом деле достаточно бы было просто чуть более развернуто объяснить свою рекомендацию (почему лучше так, а не иначе). Я нигде не встречал подобных решений. 

    Может будут еще какие мнения? :)

    13 октября 2014 г. 10:39
  • DAG это кластер. Он может работать только на скоростных и надежных, резервированных каналах. Если у вас такого нет, то следует рассматривать каждый офис как отдельный, изолированный узел - например, сайт со своим DAG (как вариант).

    Сазонов Илья http://isazonov.wordpress.com/

    13 октября 2014 г. 12:39
    Модератор
  • DAG это кластер. Он может работать только на скоростных и надежных, резервированных каналах. Если у вас такого нет, то следует рассматривать каждый офис как отдельный, изолированный узел - например, сайт со своим DAG (как вариант).

    Сазонов Илья http://isazonov.wordpress.com/

    Илья, добрый день!

    У нас очень хорошие каналы, поэтому допускаем "толстый" трафик в центральный офис со всех филиалов.

    13 октября 2014 г. 13:16
  • Любой ИТ проект должен решать задачи бизнеса. Поэтому вам нужно понять как хочет работать бизнес в разных ситуациях.

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

    Другой вариант, если ваши филиалы постоянно "отваливаются", но бизнес хочет, чтобы они работали "автономно".


    Сазонов Илья http://isazonov.wordpress.com/

    13 октября 2014 г. 13:25
    Модератор
  • Любой ИТ проект должен решать задачи бизнеса. Поэтому вам нужно понять как хочет работать бизнес в разных ситуациях.

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

    Другой вариант, если ваши филиалы постоянно "отваливаются", но бизнес хочет, чтобы они работали "автономно".


    Сазонов Илья http://isazonov.wordpress.com/

    Вот уже ближе к делу! :) Почему именно 1 сайт, а не разносить?
    13 октября 2014 г. 13:58
  • Давайте всё же исходить из объективной реальности ВАШЕЙ ситуации. Что нужно вашему бизнесу в первую очередь? Какие требования? Затравку я вам дал.

    После этого можно будет предложить решение и обосновать его.

    А так можно бесконечно говорить не о чём.


    Сазонов Илья http://isazonov.wordpress.com/

    13 октября 2014 г. 15:32
    Модератор
  • Давайте всё же исходить из объективной реальности ВАШЕЙ ситуации. Что нужно вашему бизнесу в первую очередь? Какие требования? Затравку я вам дал.

    После этого можно будет предложить решение и обосновать его.

    А так можно бесконечно говорить не о чём.


    Сазонов Илья http://isazonov.wordpress.com/

    Нам нужна прежде всего экономия. В остальном у нас хорошие каналы и хорошее оборудование. Я ознакамливался с описаниями на технете разнесенных DAG групп, но нигде не могу найти уже предложенного мне решения, о котором я написал в первом посте. В частности, мне бы просто хотелось знать - можно ли так (без объяснения), а если нет, то почему. Мне прям вас всех пытать приходиться подсказать мне ответ "Подойдет ли такое решение, если бюджет на кол-во серверов сильно ограничен?" :) 
    14 октября 2014 г. 2:46
  • Если исходить из того, что вы написали (пользователи в нескольких филиалах, хорошие каналы и минимум затрат), то вам нужно разместить почтовую систему в центральном узле: это самое простое и самое дешевое решение, и никаких оснований его усложнять разнесением по филиалам у вас нет.

    Второй вопрос это наличие балансировщика.

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


    Сазонов Илья http://isazonov.wordpress.com/

    14 октября 2014 г. 4:22
    Модератор
  • "разместить почтовую систему в центральном узле"

    Это значит исключить почтовые сервера из филиалов? Не подходит, т.к. нет отказоустойчивости на случай выпадения центрального узла. Проект создается с перспективой, где кол-во пользователей филиалов будет возрастать от 10 до  ~1 000. Мне же сейчас просто нужно услышать аргументы "ЗА" и "Против" решения предложенного нам. Я так понимаю, что технических трудностей, реализовать такую схему не возникнет?MS теперь не настаивает на разделение по сайтам филиалов, как это было раньше (выше рекомендовали сделать на двух сайтах вместо 5)? 

    19 октября 2014 г. 5:07
  • А почему у вас будет "выпадать" центральный узел? Каналы у вас уже резервированные. Остальное то же можно сделать более надежным: это обойдется дешевле, чем покупать оборудование для филиалов, лицензии, тратить средства на эксплуатацию этого всего избыточного хозяйства.

    Что касается прогноза "от 10 до 1000", то это какая-то фантазия. Если руководство кампании уже приняло решение и создаёт филиал, то цифры, сроки и выделенные деньги должны быть более конкретными.

    Опирайтесь на эти конкретные цифры для расчета: по рекомендациям производителя почтовая система рассчитывается с запасом в 10%, максимум 20 % на несколько лет.


    Сазонов Илья http://isazonov.wordpress.com/

    19 октября 2014 г. 5:33
    Модератор
  • Про каналы, что-то не могу найти где я это писал?! :)

    Нет, у нас идет отказ только от падения интернета, т.к. он не резервируется (и вряд ли будет) на филиалах. Филиалов много, до многих еще подсчет не дошел, но нужно сформировать решение, по которому мы будем идти. С цифрами я немного утрировал, но до 500 пользователей должно быть, те 10 человек пока с ноутбуками мебель расставляют :) У нас все на виртуализации, поэтому мы можем гибко подстраиваться под изменение нагрузок.

    Я так понял, тут не дождаться :)

    23 октября 2014 г. 5:31
  • Чтобы получить конкретные ответы, надо задавать конкретные вопросы и предоставлять конкретные данные. Вы не делаете ни того и ни другого. Какой вопрос - такой ответ.

    Сазонов Илья http://isazonov.wordpress.com/

    23 октября 2014 г. 6:03
    Модератор
  • Чтобы получить конкретные ответы, надо задавать конкретные вопросы и предоставлять конкретные данные. Вы не делаете ни того и ни другого. Какой вопрос - такой ответ.

    Сазонов Илья http://isazonov.wordpress.com/

    Илья, не представляете даже, специально в Visio нарисовал схему, чтобы ни единого вопроса не возникало! :) Понимаете, не важны объемы, не важны мощностя. Вопрос был - будет ли работать такая схема отказоустойчивости или нет и если нет,то почему?

    Данные:

    1. 5 сайтов
    2. 5 серверов (CAS + MBX)

    Вопрос:

    Получится ли в каждом сайте установить 1 сервер, а копии баз переместить в центральный объединив все сервера в единую группу?

    Ну право, не ловко как-то получается... 

    23 октября 2014 г. 15:15
  • DAG это кластер. Он может работать только на скоростных и надежных, резервированных каналах. Если у вас такого нет, то следует рассматривать каждый офис как отдельный, изолированный узел - например, сайт со своим DAG (как вариант).

    Сазонов Илья http://isazonov.wordpress.com/


    Так вам уже дан полный и обоснованный ответ.

    Сазонов Илья http://isazonov.wordpress.com/

    23 октября 2014 г. 17:30
    Модератор
  • А на скоростных, надежных но не резервированных он не установится? Не встречал такое в требованиях. Если такое есть, то вопрос снимается, если нет, то буду сам смотреть тогда, видимо тут никто с таким не сталкивался, потом отпишусь, может кому-то поможет в дальнейшем. 
    24 октября 2014 г. 3:08
  • Требования к сети определяющие нагрузку.

    Planning for high availability and site resilience

    • Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 500 milliseconds between each other member. As the round trip latency between two Mailbox servers hosting copies of a database increases, the potential for replication not being up to date also increases. Regardless of the latency of the solution, customers should validate that the networks between all DAG members is capable of satisfying the data protection and availability goals of the deployment. Configurations with higher latency values may require special tuning of DAG, replication, and network parameters, such as increasing the number of databases or decreasing the number of mailboxes per database, to achieve the desired goals.

    • Round trip latency requirements may not be the most stringent network bandwidth and latency requirement for a multi-datacenter configuration. You must evaluate the total network load, which includes client access, Active Directory, transport, continuous replication, and other application traffic, to determine the necessary network requirements for your environment.

    А насколько будет загружена сеть, зависит от вашей архитектуры Exchange. 

    Например для 20 000 пользователей и DAG между двумя сайтами, только на репликацию понадобится 96 MB/s.

    Если у вас каналы не резервируются и не будут соответствовать требованиям, то ваш DAG не будет корректно работать, и постоянно будет отключаться реплика в удаленном офисе.

    ЗЫ. Таких запросов, как у вас видел кучу, но как только доходит до стоимости всего того, что описано в хотелках, все вопросы закрываются и Exchange разворачивается в центральном сайте.

    ЗЫ2. По мимо этого вы не учитываете, стоимость обслуживания всей вашей инфраструктуры Exchange. Бекапы, обновления, мониторинг, запросы пользователей, поддержка актуального DR.  

    Считаю дальнейшее обсуждение не интересным и пустым. Успеха вам и вашим начинаниям. 


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    24 октября 2014 г. 5:42
    Модератор