none
Распределенная инфраструктура для CRM 2016 между площадками. RRS feed

  • Вопрос

  • Доброго дня Уважаемые коллеги.

    Имеем следующую ит-инфраструктуру для CRM 2016 -> Площадка в МСК, два сервера (CRM Server 2016 и SQL Server 2014).База в 90 гигабайт. Есть площадка в СПБ и канал передачи данных в 100 мегабит между СПБ и МСК. Сейчас из питера работам с CRM через web-приложение, но к сожалению есть негативный юзабилити в плане больших задержек, как при работе с приложением CRM, так и по каналу передачи данных (задержки до 128 м/сек).

    Задача: Внедрить распределенную конфигурацию для CRM, для того что бы иметь реплицируемую локальную копию базы в 90 гигабайт на SQL сервере в СПБ. Я так понимаю необходимо будет организовывать так же два сервера CRM и в СПБ. А для SQL внедрять реплику на базе AlwaysOn ?

    Инфраструктура: В рамках леса domain.ru есть два домена- корневой domain в котором и находится инфраструктура CRM на площадке в МСК. И есть так же поддомен spb.domian.ru используемый на площадке в СПБ. 

    Вопрос реализации: Есть ли решение по кластеризации SQL для репликации базы на уровне AlwaysON, если CRM в МСК находится в своем корневом домене + своя подсеть и то, что необходимо внедрить CRM на площадке в СПБ будет находится в другом поддомене и со своей подсетью ? То есть само решение о кластеризации SQL и реализации AlwaysON позволит ли развернуть такое решение в разных доменах и в разных подсетях ? Может есть официальные рекомендации от МС ? Смотрел на технете, но для распределенных инфраструктур не нашел...

    Но в любом случае, коллеги в МСК не хотят глобально ничего менять и мне видится только один вариант- в пределах одного корневого домена реализовывать кластер для SQL, то есть растягивать домен на две площадки с одинаковой подсетью..

    Плюс так же немаловажно лицензирование. Сейчас у нас используются два SQL редакции Standard для 1C. То есть позволит ли данная редакция реализовать AlwaysOn из двух нод для одной базы, или двух ? Плюс SQL CAL для доступа к самому серверу SQL исходя из кластерной реализации..

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 9 июля 2019 г. 7:39

Все ответы

  • Так же немаловажен вопрос того, что при реплике базы изменения в базу CRM будут вноситься с обоих сторон, как для локальной копии базы в МСК там и СПБ. И вообще поддреживается ли такой вариант MS SQL ?

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

    Спасибо.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 июля 2019 г. 11:02
  • Интересно поддерживает ли CRM репликацию слияния ? 

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 июля 2019 г. 12:56
  • Добрый день,

    IMHO то что вы хотите в CRM не поддерживается. По крайней мере упоминаний про такую реализацию нет. Думаю вам следует начать с оптимизации (https://blog.westmonroepartners.com/5-ways-to-improve-microsoft-dynamics-crm-performance/), в частности компрессии.  Также может помочь разделение CRM на бэкэнд/фронтэнд, причём фронтэндов может быть несколько, но только в режиме NLB кластера (т.е. раскидать их по сайтам можно только в случае L2 связности).

    10 июля 2019 г. 6:42
  • Михаил, доброго дня. Тут вопрос сложнее. в МСК уже реализована CRM состоящая из двух серверов первый (frontend backend) и второй собственно SQL. Между МСК и СПБ есть специально выделенный канал, который не особо устойчив и в ближнесрочной перспективе никто резервом и оптимизацией канала заниматься не собирается. А так же что-то оптимизировать и менять в CRM в МСК никто не даст, так как юридически это разные организации, хоть и холдинг. Пользователи в СПБ через браузер сейчас используют web-приложение CRM frontend- сервера в МСК (некоторый функционал таблиц из базы, который нам предоставили). Соответственно идет запись или изменение данных, которое пишется в SQL на сервер так же в МСК. Со слов коллег из МСК, на их площадке все запросы и работы осуществляется без задержек, это и понятно.

    Руководство в СПБ решило закупить оборудование в количестве двух серверов на площадку в СПБ для того что бы:

    Первый вариант:

    1.Оптимизировать скорость работы с CRM

    2.В случае падения канала между МСК и СПБ использовать свою локальную копию frontend backend b SQL  базы данных, НО так, что бы это все синхронизировалось с базой московской.

    Естественно есть решение AlwaysOn для реплики баз, но дело в том, что одна база используется только для чтения, а другая для записи. Но условия таковы, что отдел продаж работает как в СПБ, так и в МСК и соответственно должен вносить изменения с обоих сторон. Ясно что другая реализация реплик в SQL под CRM не поддерживается.

    Второй вариант:

    Полностью отделение базы от МСК в свой CRM, но тут опять возникают вопросы в части:

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

    2.Если мы отделяем инфраструктуру CRM, то здесь так же встает вопрос лицензий....

    Выводы:

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

    Спасибо! Попытался объяснить со своей колокольни как технарь..


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    10 июля 2019 г. 9:14
  • Добрый день,

    IMHO то что вы хотите в CRM не поддерживается. По крайней мере упоминаний про такую реализацию нет. Думаю вам следует начать с оптимизации (https://blog.westmonroepartners.com/5-ways-to-improve-microsoft-dynamics-crm-performance/), в частности компрессии.  Также может помочь разделение CRM на бэкэнд/фронтэнд, причём фронтэндов может быть несколько, но только в режиме NLB кластера (т.е. раскидать их по сайтам можно только в случае L2 связности).

    Михаил, доброго дня.Хотел уточнить несколько моментов.

    Если мы говорим об оптимизации CRM, то стоит ли такое решение размещать на двух отдельных локальных серверах (CRM+SQL) с использованием SSD/NVMe дисков для увеличения производительности ? - такое решение поддерживается и есть ли практики такого внедрения ?

    Если мы говорим об отказоустойчивости, то на сколько я понимаю есть три решения (которые мне известны):

    1-Если у нас CRN на платформе виртуализации vmware и в HA кластере, то выход из строя хоста виртуализации позволит перезапустить виртуальные машины с CRM на другом хосте, но если падает само приложение внутри виртуалки- отказоустойчивости нет.

    2. Организовать FronEnd сервера на NLB кластере, что позволит иметь доступ к APP при отказе одного из узлов. 

    3.Кластеризовать сам Instance где находится база средствами самого SQL Server, то есть два SQL сервера на разных хостах виртуализации (либо на двух локальных серверах), соответственно если отказывает узел, либо прилоежние, то Instance работает на другом узле в кластере SQL. Решение хорошее, но требует лицензии Enterprise+ если используем ядра, то лицензия Core на 2 ядра стоит дорого, а если ядер по 8-12 на каждом CPU их по два на сервер=дорогостоящее решение.

    4.Использование AlwaysOn- то же самое - дорого.

    Какое решение предпочесть ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    13 августа 2019 г. 7:41
  • Добрый день,

    По поводу SSD - это больше относится к  операционной системе, а не к приложениям (в плане поддержки). Да, будет прирост в производительности, но на сетевую задержку (как в вашем случае) никак не повлияет.

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

    А вам, я так думаю, стоит посмотреть чем таки у вас занят канал связи между сайтами, возможно настройка QoS может решить вашу проблему не трогая CRM. Если канал совсем плох, как вы говорите, то можно дойти вплоть до публикации CRM на площадке МСК наружу и работе с ней с другой площадки через Инет, а не через ненадёжный канал. IMHO опять же ).

    13 августа 2019 г. 8:17
  • По SSD/NVMe - допустим, на сервере СУБД мы можем расположить на одном из дисков саму базу CRM, а на другом TempDb.

    Ну вот есть пару серверов в МСК на которых работает CRM. В МСК говорят, что все у них работает оперативно быстро. У нас же соответственно при жестких требованиях для прямого канала, задержка до 18 мс.

    Сейчас согласовано обновление парка серверного оборудования и все оборудование решено разместить в ЦОД-е (физически в СПБ) в одной стойке и в данных рамках нам необходимо выбрать какое то решение для удовлетворения условий оптимизайии и отказоустойчивости с учетом того, что непонятно - останется ли исходная часть CRM в МСК, либо все переедет в ЦОД. приходиться лавировать на ходу.



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    13 августа 2019 г. 8:40
  • Михаил, доброго времени суток.

    В общем и целом пришли к то му, что для начала необходимо разнести сервисы по ролям, так как все крутится на двух серверах где и front и back и там же нагрузочное тестирование проводится, отчетность и т.д. все это приводит к такой нагрузке при которой все просто встает колом. Будет логичным рапределить фронты и репортеры по разным виртуалкам.

    В связи с чем есть пару вопросов, если позволите:

    1.Если разносить роли, то с точки зрения лицензирования (еще 2016 версии), надо ли будет покупать дополнительные лицензии при установке ролей на разные сервера ? может есть где почитать, так как по CRM у MS огромное количество материала и лавировать в нем сложновато.

    2.Система еще 2016 версии. Microsoft давно изменил и политику лицензирования и продукты уже Dynamics 365. В данном случае, на сколько сложно будет переходить к новым версиям с технической точки зрения и лицензионной политики ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    29 августа 2019 г. 18:57
  • Добрый день,

    По лицензиям лучше обратиться к поставщику, а что касается Dynamics 2016 и 365 - это, фактически, просто расширенное обновление, с технической точки зрения, подробнее по установке  можно почитать здесь.

    9 сентября 2019 г. 6:08