Paromshick
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Тема ушла в офтоп, а потому я чуть пошучу и закончу
contrafack
Цитата:| сложно представляю что надо делать. |
Ну, вы как бы начните. Сейчас сервис у вас в работе, и ОК. Приехало новое железо - начинайте с ним работать.
Или вы хотите по этапам? Вот в понедельник вы качаете и готовите дистрибутивы. Во вторник занимаетесь железом, осматриваете, при необходимости шьете, пробуете инсталить. В среду - время поработать - инсталите всё, что только можно инсталить (когда эта ерунда со средой закончится? (С)). В четверг, конфигурируете и настраиваете всё, что настраивается. В пятницу... Пятница - день бэкапов.
Знаете, когда я делал "готовое решение", то у меня было все описано в документе формата pdf для всех. Для сборщиков - какого цвета патчкорд куда втыкается, для цисковика - ТЗ по настройке циски, для админа, что как и с какими параметрами ставить...
Это стоило времени, само написание, и стоило денег  МС сейчас идет к тому, что все это ппишется в километровом скрипте на powershell...
Вам же помогают посильно всем форумом. Вы начните, а оно пойдет. Пока сервис в продакшн не сдадите всегда сможете сделать любимый формат Цэ
Newbie
Раз вы отвечаете на мою цитату, то предположу, что отвечаете мне.
Цитата:| Перезапускается - это значит холодный старт операционной системы виртуального сервера. Незаконченные транзакции, несброшеный кэш - это норма риска. |
Вот несогласный я. В SQL горячо запущенный движок подхватывает диски, базы и цепляя IP начинает отзываться так, как будто ничего не произошло. Даже реконнекта нет. Небольшая "задержка в сети" для клиента и всё. Конечно, если в момент сбоя шла транзакция, то она не завершается, НО повторяется. Механизм защиты транзакции от сбоя - в дизайне самой транзакции. Которая считается НЕ завершенной, пока НЕ произведена последняя запись на диск (по ссылке я коротко об этом обмолвился (последнее предложение первого абзаца), но меня не поняли). А диск - не сбоил.
Таким образом, мы приходим к тому, а что всё-таки называть failover (не NLB)кластером? Ведь можно
- Поставить две ноды в кластер средствами "железа", то есть гипервизора. У всех такая возможность есть. Холодная нода - теневая копия "горячей" с задержкой на репликацию. Тогда, в общем случае, нет необходимости в общем хранилище вовсе. Так же, "холодная нода" не занимает пространство в RAM. Ноды можно располагать в разных концах планеты. Старт холодной ноды процесс инерционный, имеются "противопоказания", вопрос о перенацеливании клиентов - вопрос индивидуальный. В случае нахождения нод в одной подсети и даже VLANе, им можно пренебречь.
- Поставить две ноды в кластер средствами ОС. Две постоянно работающие машины. Обе (каждая) занимают пространство в RAM и требуется диск кворума - общий ресурс. Говорят, что сейчас можно без него. Не пробовал и не хочу, ибо просто две работающие машины сами по себе - не интересны. Интересен сервис(ы), который(е) они обслуживают, а у них, как правило, есть некая "общая база". Но, указанный вариант может быть интересен для кластеризации сервисов, такой базы не имеющих, либо имеющих, но нечто "квази". Файл конфига например, который копируется раз в год вручную.
- Поставить в кластер две ноды средствами приложения, как пример - описанное выше поведение MS SQL. Этот вариант наиболее распространён (в моей практике), но, как правило, требует использования в своем дизайне и второго варианта, но главное - общего хранилища. Здесь - можно делать ваще_всё.
- Какой-то дикий микс, когда это оправдано или "душа просит". Не рассматриваю. Штучный дизайн.
Вот такой оффтоп.
Есть тема по кластерам? Да и есть ли что обсуждать?
Добавлено:
Цитата:
Вагон. И маленькая тележка
Оказывается, я в одной даже поучаствовал. Человек попытался географически разнести ноды кластера, выстраиваемого по второму варианту. Что-то у него случилось, кто бы мог предположить
Не надо так делать. Помимо общей бессмысленности, еще и сбойное решение, то есть не fail over, но fail forever получается.
Зачем? 
Добавлено:
Цитата:
Я не тормоз, я медленный газ, это про меня
Начать можно с одной ноды, потом добавлять. Отказоустойчивость возникает при числе нод не менее двух. Масштабируемость системы возникает сразу.
Масштабируемость, гибкость, прозрачность. Отсюда растёт всё остальное, отказоустойчивость, надежность, совместимость и... ИМХО, вообще всё. Если говорить про Систему. Именно Систему.
|
