Цитата:
Сообщение от
ax_mct
Я правильно понимаю что необходимость такого железа это из-за кривизны архитектуры решения?
Или там In-Memory technologies in (Azure) SQL Database и все летает?
Проблема в Azure Service Fabric, которая изначально разрабатывалась под кровавый entterprise и на маленьком числе VM работать не умеет
Более интересно то, что до недавнего времени вполне работоспособные на среднем числе пользователей окружения уровня Tier-1 и Tier-2 деплоились на основе обычного IIS и работали на всего паре VM+ база данных где-то в Azure. То есть - не было и нет никаких технических ограничений для того чтобы Microsoft выпустил бы D365FOE On Premise SMB, которое требовало бы двух-трех виртуалок+SQL Server. Но они из за чмошно-маркетинговых побуждений выпустили On Premise на основании тяжелейшей архитектуры. Кроме того, есть сильное подозрение, что продуктивные инстанцы в облаке, на самом деле, до сих пор работают на основе IIS. Микрософт только недавно начал ASF-based окружения в TEST деплоить, причем не во всех регионах. То есть - похоже что микрософтовцы просто решили за счет тех клиентов, кому On Premises нужен просто протестировать альфа-версию ASF-based D365FOE.
Касательно числа ядер для SQL Server: Я видел несколько достаточно больших (типа 200-300 пользователей) внедрений DAX2009/DAX2012 (причем нормально сделаных, без грязного переписывания). Так вот при 16 ядрах у SQL Server, логистика там работала без огонька. Так что при числе пользователей выше 300 я бы думал о где-нить 32 ядрах на SQL Server. Проблема в том что с каждой новой версией SQL Server, стоимость лицензии на ядро росла. Во времена DAX2009 и SQL Server 2008R2, стоимость SQL Server была сопоставима со стоимостью железа, на котором он исполнялся. Сейчас стоимость Enterprise Edition SQL Server 2016/2017 явно раза в 3-4 выше стоимости железа.