Каморка

Забацал таки скажем нет монополии Оракла.

На двух серверах 2012 R2, подсоединённых к iSCSI SAN, на них сконфигурёны два CSV (Clustered Shared Volume), failover автоматический. Сверху на них же поставлены две instances Clustered SQL 2014, каждая сделана Owner на своём CSV, failover автоматический, failback ручной (чтобы сначала разобраца чё ето было).

По сети клиэнты коннектятся к Clustered Names, индивидуально к нодам доступа нет. Если олин падает - failover time ~35-55 секунд и опаньки! всё продолжает работать впрочем как сконфигуришь. Все атлично проверено всеми способами - и шнуры питания из розетки выдяргавал, и ребутил, и свич выключал, и сервисы подвешивал.

Естественно, должна наличествовать вся M$ инфраструктура, AD, DNS.

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

Шэф писал(а):Забацал таки скажем нет монополии Оракла.

На двух серверах 2012 R2, подсоединённых к iSCSI SAN, на них сконфигурёны два CSV (Clustered Shared Volume), failover автоматический. Сверху на них же поставлены две instances Clustered SQL 2014, каждая сделана Owner на своём CSV, failover автоматический, failback ручной (чтобы сначала разобраца чё ето было).

По сети клиэнты коннектятся к Clustered Names, индивидуально к нодам доступа нет. Если олин падает - failover time ~35-55 секунд и опаньки! всё продолжает работать впрочем как сконфигуришь. Все атлично проверено всеми способами - и шнуры питания из розетки выдяргавал, и ребутил, и свич выключал, и сервисы подвешивал.

Естественно, должна наличествовать вся M$ инфраструктура, AD, DNS.

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

Ни хера не понял, кроме того, что Шэф крут

Крут то крут, но свичей, по идее, должно быть два...

вот ради интререса - сколько стоит такое решение - интересуют собственно лицензии всего без чего все это хозяйство не взлетит.

Stanislav писал(а): должно быть два...

занудо.
конечно свичей по 4 в рэке: по 2 на SAN, по 2 на LAN, все SAN через рэки соединены LAG-ами в loop, то же самое все LAN свичи каковые также хэндлят и vMotion, да ещё отдельный loop сделан для management network
"свич выключал" в смысле порты дисаблил к серваку чтоб failure сымитировать, оба свича выключить - как ж тогда который живой останецца?

Stanislav писал(а):Крут то крут, но свичей, по идее, должно быть два...

и серверов 3, чтобы split-brain корректно разрешался.

borei писал(а):вот ради интререса - сколько стоит такое решение - интересуют собственно лицензии всего без чего все это хозяйство не взлетит.

МС СКЛ лицензируется на кор или на кол-во кал, т.е. в зависимости от хардваре или кол-ва клиентов цены могут быть от и до...

borei писал(а):вот ради интререса - сколько стоит такое решение - интересуют собственно лицензии всего без чего все это хозяйство не взлетит.

фиг его знает. Ну посчитайте, у M$ где-то вроде калькулятор есть.
Простой для бизнеса обойдётся дороже чем лицензии, такшта пофик. Но мы Gold партнер (чему моё наличие в компании весьма способствует) и у нас большая скидка

Шэф писал(а):

Stanislav писал(а): должно быть два...

занудо.
конечно свичей по 4 в рэке: по 2 на SAN, по 2 на LAN, все SAN через рэки соединены LAG-ами в loop, то же самое все LAN свичи каковые также хэндлят и vMotion, да ещё отдельный loop сделан для management network
"свич выключал" в смысле порты дисаблил к серваку чтоб failure сымитировать, оба свича выключить - как ж тогда который живой останецца?

Ну мало ли! А может я у тебя SPOF заметил?

у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.

borei писал(а):у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.

У вас проблемы? Используйте решения VMware!
VMware 6 поддерживает 4 CPUs FT

Stanislav писал(а):

borei писал(а):у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.

У вас проблемы? Используйте решения VMware!
VMware 6 поддерживает 4 CPUs FT

да ну на, еще вмварь тащить. А с чем CPU FT едят ??

borei писал(а):у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.

это у вас - host-standby, а у нас оба сервера полезную работу делаютъ. В этом и весь писк: каждый толерантен к load spikes вполне таки, т.е предполагается будет загружен до 70-80%, что в сумме даст 160% / 2 против ваших 100% / 2.
Кроме того - да, уже щас очевидно что ноды можно будет просто добавлять. Не split-brain ради, а scalability для.

borei писал(а):

Stanislav писал(а):

borei писал(а):у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.

У вас проблемы? Используйте решения VMware!
VMware 6 поддерживает 4 CPUs FT

да ну на, еще вмварь тащить. А с чем CPU FT едят ??

Не скажи! Я куплю потом
FT - это когда VMware создает и синхронизирует теневую VM на кластере и если один сервак сдыхает, она тут же переключается на теневую с зеро-даунтаймом - гламурненько так получается. До версии 6 такой выверт работал только для VM с одним CPU - маловато будет, а теперь уже 4 - вполне себе ничего.

borei писал(а):да ну на, еще вмварь тащить. А с чем

Вабще-то есть смысл на вмварь их тащить, уже очевидно. Я сначала думал нет, а теперь буду. SD-модули вот токо прикупим. Причины:
- гораздо быстрее reboot, если приспичит;
- гораздо лучше networking, т.к. load-balancing отделён от операционки и будет делаться вмварью;
- и ещё пара причин потончее, но так я вам всё и рассказал