none
Exchange 2016 и отказоустойчивость RRS feed

  • Вопрос

  • 16 пока не ставил, пока почитал только но не нашел ответа на неск. вопросов.

    1. Возможна ли конфигурация - стоят 2 сервера с ролью mailbox, а в качестве хранилищ под БД в обоих юзать iSCSI? Не для каждого свою, а общую? Или там отказоустойчивость только дополнительной базой и репликами обеспечивается? Места мало...

    2. Что посоветуете в качестве балансировщика? Dns RR не подходит, если один из серверов упадет, половина коннектов отвалится. Народ пишет про HaProxy\Nginks, а под винду есть что-то кроме nlb и желательно с обратной связью?

    3. Пограничных серверов может быть >1? Например 2. Если одинаковое письмо сразу на оба придет, они разберут, что это одно и тоже письмо?

    Ms старательно выпиливает нужные фичи от версии к версии, чтобы в конечном итоге всех в облака загнать с фикс.платой за сервис :(


    • Изменено GuSoft 26 февраля 2019 г. 15:05
    26 февраля 2019 г. 15:03

Ответы

  • 1. Нельзя, ибо LUN будет доступен только одному хосту в конкретный момент времени. Вы можете дешевые SATA закупить для второго хоста, подключить их как DAS и разместить там копии БД, если на СХД совсем мало места.

    2. Если денег нет, то просто используйте DNS RR. У вас нет опыта в администрировании Linux, и если по какой-то причине балансировка HAProxy ляжет, то не факт что быстро сможете разобраться.

    3. А зачем вам нужен Edge?

    27 февраля 2019 г. 5:52
  • 1. Ну если работать будет, то почему бы нельзя))

    3. Объясните зачем вам нужно, чтобы письмо шло враз на два пограничника? Даже если придет на один, у эксча есть встроенные механизмы обеспечения избыточности

    Ну значит в развертывании эксча на земле именно ваш личный интерес, а не выгода конторы))

    В 2013 эксче были роли CAS и MBX. В 2016 обе эти роли объединили в одну - MBX. То есть, сделали лучше. Что конкретно вас не устраивает? Вы изучали ченджлоги новых версий?

    Не понимаю о каком своем облаке вы говорите. При чем тут эксч 2016 и 2019? Коллега, я вас прошу привести конкретные примеры, а вы, извините, только ноете, что все становится только хуже. Ещё раз: примеры обрубленного функционала, который так был вам необходим, в студию. На счет центоси: редхат не располагает аналогичными microsoft ресурсами и поэтому за бесплатно имеет армию тестировщиков функционала центос, который потом переносит в redhat и делает платным. Хитро придумали?

    1. Локальные версии останутся надолго, не переживайте. Но что приоритет развития - облако, это факт.

    2. Из каких старых ОС/серверов/сервисов? Может я просто плохо помню, но в голове не появляется ни один пример продукта МС, который бы они отказались поддерживать и перевели полностью в облако. Разве что S4B, но он был изначально кривым и малополезным и переход на тимс многих обрадовал.

    3. Телеметрия в ПО уже ооочень давно. Собственно практически сразу как начал хоть как-то развиваться инет, появился сбор данных. Это делают все, не только мс, не переживайте. Например ваш бесплатный андроид на смартфоне уже насобирал целую библиотеку о вас.

    4. Вообще такой договоренности даже не надо, вполне нормально для старого ПО и ОС заканчивать поддержку современного железа. Это логично.

    5. Пошло что-то на грани теории заговора. Пруфы, пожалуйста.

    6. А автомобили, в том числе премиум-сегмента, которые постоянно ломаются и которых надо возить на ТО чуть ли не каждые 5к км? Уже можно и не мечтать о моторах-миллионниках, любой движок даже на bmw, мерсах сыплется после 300к км. Это по-вашему что такое? Можно называть теорией заговора, а можно называть сменой эпохи. Раньше была в цене долговечность, сейчас в цене все новое, максимально функциональное, но удешевленное в пользу снижения долговечности. Сейчас требования мира таковы. Это ни хорошо, ни плохо, просто вы не успели перестроиться

    27 февраля 2019 г. 6:30
  • 3. Во все ПО внедряется телеметрия, с отчетами по всем вашим действиям. Даже на этапе разработки, например в VC

    Тут заказал собрать отчет на меня одной "Security компании" за деньгу малую, таки занимательное чтиво. Вы не переживайте так, все кому надо, о вас все знают, если что так сразу.

    MCITP, MCSE. Regards, Oleg

    1 марта 2019 г. 13:31
    Модератор

Все ответы

  • Добрый вечер.

    1. В официальной документации все расписано, не поленитесь прочитать:

    Don't share physical disks backing up Exchange data with other applications. 
    Use dedicated storage networks. 
    Use multiple network paths for stand-alone configurations.

    О какой отказоустойчивости вы говорите, если собираетесь двум эксчам дать доступ к одной и той же хранилке? Если хранилка грохнется, толку от ваших двух эксчей будет ноль. Используйте DAG, но базы храните на разном железе (не на разных дисках, а на разных хранилках/серверах)

    2. Посоветую HAProxy, как одно из лучших решений, к тому же бесплатных. Нормальной балансировки на винде нет.

    3. Может быть и >1. Если одинаковое письмо придет на два разных сервера, то это будет уже не одинаковое письмо (разные отметки времени, разные доп. заголовки от каждого сервера и тп). Да и как вы вообще себе это все представляете? Распишите подробно, пожалуйста.

    Уточните какие фичи вы имеете в виду. Облака - очень неплохой вариант, по многим параметрам даже лучший (уж явно лучше вашего решения с одной скази-хранилкой=))).



    • Изменено Egor Vasilev 26 февраля 2019 г. 15:57
    26 февраля 2019 г. 15:55
  • Спасибо за ответ.

    1. Хранилка _очень_ отказоустойчивая (вообще там их 2, точка входа одна - это кластер на базе synology, для небольшой конторы - хватает с головой). А вот с остальным местом беда. Но это возможно? Речь же не о всамомделишных "физических" дисках?

    2. Ок

    ++ Я вот нашел на гитхаб версию HaP под винду. Не вкурсе, юзал кто для таких целей и какие ограничения? https://github.com/letssudormrf/haproxy-windows (с cеntos честно говоря опыт не большой)

    3. Тема такая. Установлен Usergate UTM. У него есть публикация почтовика. Но внешний стат. IP к сожалению 1 (и не ясно купят ли 2, скорее всего нет).

    Там есть правило проброса smtp с проверкой на вири и спам. А серверов пограничных планирую 2. Еще один балансировщик перед ними - накладно. А у UG в правиле можно проброс\публикауцию сразу на несколько Ip сделать. Т.е. создаем правило публикации слушаещее и сразу на 2 Ip пограничных посылаем. Не прокатит? 2 сервера хочется, чтобы если с 1м косяк или обновление - канал бы оставался наружу. Или что посоветуете?

    ++

    Фичи - какие обсуждаем - ранее можно было сделать все отдельно и из коробки, а сейчас этот гимор.

    Ну вот уж нет :) Множество "против" у меня (и не только) есть. Минусов больше. И кто мешает свое облако сделать на своих ресурсах? Но нет, из стандартного ПО эти возможности старательно вырезаются.








    • Изменено GuSoft 26 февраля 2019 г. 19:16
    26 февраля 2019 г. 18:25
  • 1. "Очень надежная" означает, что она обязательно ляжет, но не через 2 года как обычные, а через 3. В любом случае это ваше решение, ваша ответственность. К тому же бюджеты уже освоены как я понимаю.

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

    2. На счет костылей не проконсультирую, может у кого из коллег тут на форуме был опыт, подождем ответ.

    3. Балансировать smtp вам не надо. Зачем? Эта возможность и так заложена в сам протокол. Вам за балансер надо засовывать 443 порт (главным образом речь об OWA). По UG не проконсультирую, опыта не было.

    На счет фичей все же не совсем понимаю о чем вы, приведите конкретный пример.

    Как админу вам конечно интересно все запилить у себя на земле, реализовать отказоустойчивость и высокую доступность и тд и тп, но бизнесу это нафиг не надо, поверьте. Бизнесу нужны быстрые решения, за которые не надо сразу же отваливать мешок денег. А ещё лучше, если необходимость пропадет, чтобы можно было сразу безболезненно отказаться. Облака удовлетворяют этим требованиям, а ваши решения - нет. Ваше решение даже не обеспечивает базового уровня отказоустойчивости, к сожалению. Холивар не хотелось бы разводить, но если у вас есть конкретные вопросы/тезисы, можно их аккуратно обсудить.

    26 февраля 2019 г. 19:44
  • 1. Ну, в принципе, согласен. Основной вопрос остался - это можно сделать?

    2. ок

    3. вот как раз чтобы письмо шло сразу на 2 пограничника. про owa ясно.

    ++ при таком подходе (кроме кучи других минусов), основным для меня является то, что в таком раскладе штатные админы становятся не нужны. а выгода для конторы - сомнительна. ща или наш РКН очередной кусок подсети завалит или с той стороны откажутся что-то делать - и каюк данным.

    ++ >> Ваше решение даже не обеспечивает базового уровня отказоустойчивости,  к сожалению

    Вот как раз этого и хочу добиться. Еще в 2013 Exch это можно было сделать, 2 сервера на роль коннекта, 2 сервера на dag, 2 пограничника - меня все устраивало. Все отказоустойчивое. Какой в новом решении "+" для таких небольших контор и вообще в целом? Я вижу только принудиловку к переходу на облака и монетизации.

    Если бы функц.2013 был бы в Ex2019 то запросто и свое облако можно сделать. Но нет, с каждой новой версией делается все, чтобы использовать продукт было проблемно, а также выпиливаются или делаются палки в колеса для использования старых возможностей. Вы думаете это честно? И в статьях Ms по Ex2016 пишут "о новом веянии объединения ролей" хотя ежу ясно куда это ведет. Причем без альтернативы. У RedHat похожая политика, но там хотябы есть ветка CentOs и GNU лицензии царят - "боже, храни ребят, кто ее придумал".

    Какие бы вы мне не рисовали перспективы, ясно, что (да, я верю в "т.заговора", т.к. наблюдаю что это происходит на самом деле):

    1. Ms ведет свои ОС и все сервера\сервисы на всех платформах к идеалу загрузки при включении устройства с их ресурса и далее их тарифный план (за отдельную плату\мес\год)

    2. Из всех старых ОС\серверов\сервисов выпиливается возможность локальной реализации

    3. Во все ПО внедряется телеметрия, с отчетами по всем вашим действиям. Даже на этапе разработки, например в VC

    4. Для старого ПО и ОС есть договоренность с производителями железа о прекращении выпуска драйверов, а также обновлениях, которые замедляют устройство

    5. Последними обновлениями в старое ПО вносится изменения тормозящее их работу

    6. В железо\ПО вставляются "козлики" - кот, через 1-3 года бодаются (был старый фильм в ссср (назв.не помню) про воров в законе, там на схолдке человеку объясняли как надо видомагнитофоны чинить - починил, вставил козлика, через 2 мес снова принесут).

    + вот, если не смотрели https://youtu.be/8nscGJLPh3Mbp

    Ну не сделать из этого вывод или хотя бы определить направление, куда нас тянут - крайне сложно


    • Изменено GuSoft 26 февраля 2019 г. 21:18
    26 февраля 2019 г. 20:49
  • 1. Нельзя, ибо LUN будет доступен только одному хосту в конкретный момент времени. Вы можете дешевые SATA закупить для второго хоста, подключить их как DAS и разместить там копии БД, если на СХД совсем мало места.

    2. Если денег нет, то просто используйте DNS RR. У вас нет опыта в администрировании Linux, и если по какой-то причине балансировка HAProxy ляжет, то не факт что быстро сможете разобраться.

    3. А зачем вам нужен Edge?

    27 февраля 2019 г. 5:52
  • 2. Внутренние подключения балансируются сами. Для балансировки внешних подключений можете настроить IIS ARR. 
    27 февраля 2019 г. 6:26
  • 1. Ну если работать будет, то почему бы нельзя))

    3. Объясните зачем вам нужно, чтобы письмо шло враз на два пограничника? Даже если придет на один, у эксча есть встроенные механизмы обеспечения избыточности

    Ну значит в развертывании эксча на земле именно ваш личный интерес, а не выгода конторы))

    В 2013 эксче были роли CAS и MBX. В 2016 обе эти роли объединили в одну - MBX. То есть, сделали лучше. Что конкретно вас не устраивает? Вы изучали ченджлоги новых версий?

    Не понимаю о каком своем облаке вы говорите. При чем тут эксч 2016 и 2019? Коллега, я вас прошу привести конкретные примеры, а вы, извините, только ноете, что все становится только хуже. Ещё раз: примеры обрубленного функционала, который так был вам необходим, в студию. На счет центоси: редхат не располагает аналогичными microsoft ресурсами и поэтому за бесплатно имеет армию тестировщиков функционала центос, который потом переносит в redhat и делает платным. Хитро придумали?

    1. Локальные версии останутся надолго, не переживайте. Но что приоритет развития - облако, это факт.

    2. Из каких старых ОС/серверов/сервисов? Может я просто плохо помню, но в голове не появляется ни один пример продукта МС, который бы они отказались поддерживать и перевели полностью в облако. Разве что S4B, но он был изначально кривым и малополезным и переход на тимс многих обрадовал.

    3. Телеметрия в ПО уже ооочень давно. Собственно практически сразу как начал хоть как-то развиваться инет, появился сбор данных. Это делают все, не только мс, не переживайте. Например ваш бесплатный андроид на смартфоне уже насобирал целую библиотеку о вас.

    4. Вообще такой договоренности даже не надо, вполне нормально для старого ПО и ОС заканчивать поддержку современного железа. Это логично.

    5. Пошло что-то на грани теории заговора. Пруфы, пожалуйста.

    6. А автомобили, в том числе премиум-сегмента, которые постоянно ломаются и которых надо возить на ТО чуть ли не каждые 5к км? Уже можно и не мечтать о моторах-миллионниках, любой движок даже на bmw, мерсах сыплется после 300к км. Это по-вашему что такое? Можно называть теорией заговора, а можно называть сменой эпохи. Раньше была в цене долговечность, сейчас в цене все новое, максимально функциональное, но удешевленное в пользу снижения долговечности. Сейчас требования мира таковы. Это ни хорошо, ни плохо, просто вы не успели перестроиться

    27 февраля 2019 г. 6:30
  • 3. Во все ПО внедряется телеметрия, с отчетами по всем вашим действиям. Даже на этапе разработки, например в VC

    Тут заказал собрать отчет на меня одной "Security компании" за деньгу малую, таки занимательное чтиво. Вы не переживайте так, все кому надо, о вас все знают, если что так сразу.

    MCITP, MCSE. Regards, Oleg

    1 марта 2019 г. 13:31
    Модератор