гы-ы-ыStanislav писал(а):FT - это когда VMware создает и синхронизирует теневую VM на кластере и если один

гы-ы-ыStanislav писал(а):FT - это когда VMware создает и синхронизирует теневую VM на кластере и если один
Как это? У тебя две шелезяки и у меня две шелезяки.Шэф писал(а):гы-ы-ыStanislav писал(а):FT - это когда VMware создает и синхронизирует теневую VM на кластере и если одинэто ж ещё вдвое больше денег вбухать на железо, баланс нужон между цена/выхлоп.
погодь погодь. у тебя для каждой ноды свой iSCSI LUN и в случае падения одной ноды вторая нода подхватывает LUN и стартует на нем БД ?Шэф писал(а):это у вас - host-standby, а у нас оба сервера полезную работу делаютъ. В этом и весь писк: каждый толерантен к load spikes вполне таки, т.е предполагается будет загружен до 70-80%, что в сумме даст 160% / 2 против ваших 100% / 2.borei писал(а):у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.
Кроме того - да, уже щас очевидно что ноды можно будет просто добавлять. Не split-brain ради, а scalability для.
XeN, проект Chronos уже года 3 как.Stanislav писал(а):Не скажи! Я куплюborei писал(а):да ну на, еще вмварь тащить. А с чем CPU FT едят ??Stanislav писал(а):У вас проблемы? Используйте решения VMware!borei писал(а):у меня такое решение для mysql уже 2 года как крутиться - drbd/pacemaker/corosync. да и практическт все виртуалки (которые не в облаке) так организованы.
Только все это - hot-standby решения.![]()
VMware 6 поддерживает 4 CPUs FTпотом
FT - это когда VMware создает и синхронизирует теневую VM на кластере и если один сервак сдыхает, она тут же переключается на теневую с зеро-даунтаймом - гламурненько так получается. До версии 6 такой выверт работал только для VM с одним CPU - маловато будет, а теперь уже 4 - вполне себе ничего.
да не я не втом плане, а в плане платформы виртуализации - я на Xen/XenServer сижу.Шэф писал(а):Вабще-то есть смысл на вмварь их тащить, уже очевидно. Я сначала думал нет, а теперь буду. SD-модули вот токо прикупим. Причины:borei писал(а):да ну на, еще вмварь тащить. А с чем
- гораздо быстрее reboot, если приспичит;
- гораздо лучше networking, т.к. load-balancing отделён от операционки и будет делаться вмварью;
- и ещё пара причин потончее, но так я вам всё и рассказал
Я такую архитектуру три года назад делал для почты. Но это все равно - hot-standby. Данные одного LUN доступны только одному узлу, горизонтальное масштабирование для ОДНОЙ базы - нема такого.Шэф писал(а):хе-хе, хорошие вопросы задаёшь когда пошевелишь мускулами головы![]()
На уровне ОС обе ноды пишут на оба LUNа, но каждая владеет только одним а второй крест-накрест перенаправляется. Т.е. да.
На уровне SQL каждая нода владеет только одним и пишет тольк на свой, т.е. нет. Но это ок.
А в случае failure на обоих уровнях ода нода работает за двоих.
ИИС живее всех живых. Микрософт и многие производители делают свои менеджмент приблуды с его участиемGroundhog писал(а):Вопрос: microsoft sql, IIS - в смысле "Я еще живой"? Неужто кто использует IIS как нечто иное кроме резервирования хост-имен? Эт как его программо-мазохизм? Ставить гуно и потом его разгонять?
Ватно-укропная тема затягивает и исчерпывает лимиты времени. Я все таки не соглашусь что у тебя active-active кластер. Утилизация ресурсов - да согласен, но архитектурно это всего лишь HA. В плане монтирования или конкурентного доступа к блочным устройствам - там начнется самое интересное и по моему решения кроме oraoracШэф писал(а):hot-standby, да не совсем. Я же привёл довод что железо используется эффективнее в моей имплементации.
А вроде ж у Оракла возможно такое? (могу ошибаться)
Кроме того, я так понимаю что active-active возможен, главное как проимплементить mounting points. Я сделал просто через буковки драйвов, а можно ведь и линки прописать, по-крайней мере такие случаи рассматриваются. Но нам и так уже хорошо получилось, big step ahead.
Кроме того, вааще-то на уровне ОС это уже немало, следующий этап будет IIS, и там как раз горизонтальное масштабирование получится, правда, без 10 ГБит делать нечего.
Пока я сделал на 1 Гбит, но это для backup site (но конечно network teaming везде), через пару месяцев тестирования сделаю на live и там скорее всего будет на 10 ГБит.
Под словами "лучше networking" подразумевается что по опыту (сыну ошибок трудных) оно работает лучше с одним vmnet3 10 ГБит адаптером, и система не бьётся в конвульсиях если один линк не поднялся или оторвался. Надёжнее, одним словом.
А за мой опыт мне платят пол-зарплаты. Вот просто за то, что прихожу на работу. Как там, в Moonstrike папаша семейства отлично сказал: I cost money because I save money!
Ну да занудствую немногоШэф писал(а):занудо![]()
ну хорошо, сначала цепляем третий яшшык к SAN-у, а шарим CSV на SQL-сервера через него. Аккординли спецификицыям мекросохвта усё будет работать Active-Active, не вижу причин почему нет. У меня просто нет лишних 10 МБит свичей и карт, выкрутился на том чо было.
10 ГБит конечно имелось в видунет лишних 10 МБит свичей и карт