Кластер это что в машине
Что такое кастер автомобиля и что о нем нужно знать
Угол кастера автомобиля один из наиболее важных параметров настройки подвески, от него зависит поведение автомобиля в дороге. Больше всего сложностей возникает при выборе оптимального угла для спортивных автомобилей. Кастер – это отклонение оси поворота колеса, с помощью его правильной регулировки, можно получить самоцентрирующуюся рулевую систему, которая отражается на поведении автомобиля при разгоне, движении накатом и торможении. При большом угле кастера увеличивается радиус разворота, сцепление с дорогой становится хуже, но колеса центрируются лучше.
При небольшом кастере улучшается сцепление колес с дорогой, для поездок по неровной дороге, инженеры гоночных автомобилей уменьшают угол кастера, если предстоит поездка по скоростной, 
ровной трассе, его наоборот увеличивают. Кастер влияет на развал колес в повороте, чем больше пятно контакта, тем устойчивее автомобиль. Максимальная поворачиваемость достигается при нулевом значении кастера, в таком случае подвеска и амортизаторы работают с наибольшей эффективностью и поглощают все неровности на проезжей части.
Маленький кастер увеличивает вероятность сноса передней оси, поскольку центр тяжести при ускорении начинает смещаться назад, разгружается передняя ось и колеса перестают держать дорогу. Большой кастер увеличивает вероятность сноса передней оси, улучшается управляемость автомобиля, поскольку увеличивается пятно контакта с дорогой.
Регулировка кастера производится путем снятия или добавления шайб, которые устанавливаются на растяжках подвески. Максимально допустимое их число составляет – 2 спереди и 4 сзади. Проводится регулировка кастера только вместе с регулировкой развала-схождения, иначе можно нарушить работу подвески и автомобиль будет вести себя непредсказуемо на дороге.
Регулировать угол установки колес желательно каждые 30 000 км пробега, а также после замены деталей подвески. Автосервис « Колесо.69» в Твери оснащен современным оборудованием, наши опытные специалисты выполнят все необходимые работы по ремонту, диагностике автомобиля, проведут замену деталей и проконсультируют вас по всем вопросам.
Что такое кастор, и на что он влияет
Если процедура регулировки углов развала-схождения колес является традиционной и хорошо известной, то еще один угол, имеющийся в рулевом управлении, зачастую вовсе неизвестен – отчасти за счет отсутствия возможности его регулировки на большинстве автомобилей. Сам он, однако, играет весьма важную роль в формировании правильной управляемости автомобиля. Угол этот называется кастор (или кастер). Что это за угол, и на что он влияет?
Кастор – это угол между осью поворота колеса и вертикалью. Практически во всех автомобилях управляющее колесо поворачивается не вокруг вертикальной оси, а вокруг оси, слегка отклоненной от вертикали. Если встать сбоку от автомобиля и мысленно провести две эти оси – вертикальную и ось поворота – то угол между ними и будет являться кастором. Невооруженным взглядом заметить угол кастора сложно, поскольку обычно он небольшой и составляет пару-тройку градусов, в целом не превышая 10 градусов.
Проще всего увидеть угол кастора на двухколесной технике – мотоциклах и велосипедах. У них кастор фактически совпадает с углом наклона вилки – чем больше «завалена» вилка относительно вертикали, тем больше кастор. Самый большой кастор демонстрируют выставочные образцы чопперов с очень длинной вилкой и колесом, сильно вынесенным вперед.
Исходя из геометрической логики, кастор может быть положительным, нулевым и отрицательным. Кастор является положительным, когда ось поворота колеса пересекается с поверхностью дороги по ходу движения впереди пятна контакта колеса с дорогой – иными словами, ось поворота «завалена» назад. Кастор будет нулевым, если ось поворота колеса будет совпадать с вертикалью. Ну а отрицательный кастор создается, если ось поворота колеса «завалена» вперед, и ее пересечение с поверхностью дороги находится позади пятна контакта.
Про кастор. Что это и с чем его едят…
Кастор (англ. caster angle или castor angle) — угол продольного наклона оси поворота колеса автомобиля.
Кастор измеряется в градусах и представляет собой угол в продольной плоскости автомобиля между вертикальной линией и линией, проходящей через центры поворота колеса.
Существует очень немного регулировок в спортивной автомодели, которые вызывают столько затруднений, как кастер. Похоже, что в зависимости от источника информации, существуют весьма различные мнения о эффекте регулировки кастера. Для целей этой статьи, объяснения были взяты из различных источников, и я постараюсь нарисовать ясную картину того, как работает кастер.
Что такое кастер?
Кастер является углом, под которым наклонена ось поворота колеса. Основной целью наличия кастера является получение самоцентрирующейся рулевой системы. Угол кастера влияет на поворачиваемость при накате, торможении и при ускорении, так как это наклоняет шасси больше или меньше в зависимости от величины угла кастера.
Для спортивных автомоделей, в основном рекомендуется использовать крутой угол кастера (более вертикальный) на скользких, нестабильных и неровных поверхностях, и использовать пологий угол кастера (более наклонный) на ровных поверхностях с высоким сцеплением.
Развал против кастера
Развал имеет отношение к пятну контакта шины — его задачей является поддерживать максимально возможную площадь контакта шины с поверхностью. Развал и кастер соотносятся в том, что кастер может обеспечивать ЭФФЕКТИВНОЕ ИЗМЕНЕНИЕ РАЗВАЛА, когда передние колеса поворачиваются в поворот.
Кастер оказывает эффект прогрессивного наклона передних колес в сторону поворота. Чем больше величина угла кастера (больше наклон), тем больше эффективное изменение развала при повороте колес. Это происходит потому, что верхняя часть колес НАКЛОНЯЕТСЯ в сторону внутренней стороны поворота, колеса лучше цепляются за поверхность, противодействуя центробежной силе, которая выталкивает автомодель в сторону внешней стороны поворота.
Сравните это со статическим развалом, который регулируется на автомодели, стоящей на горизонтальной поверхности и колесах направленных прямо вперед. Статический развал главным образом влияет на внешние колеса, которые несут основную нагрузку во время поворота.
Поэтому, величина переднего развала, требуемого для поддержания максимальной площади контакта шины с поверхностью, в большой степени зависит от величины кастера. Крутой угол кастера (более вертикальный) требует большей величины развала, а пологий угол кастера (более наклонный) требует меньшей величины развала.
Все это зависит от вашей точки зрения…
«Большая величина кастера увеличивает поворачиваемость при накате и торможении» или «меньшая величина кастера увеличивает поворачиваемость при накате и торможении». Откуда такое различие во мнениях? Будет ли одно правильным, а другое неверным? Нет, они оба правильные… просто это зависит от вашей точки зрения.
Первое утверждение относится к крутизне угла кастера, поэтому БОЛЬШИЙ кастер означает более вертикальный угол. Второе утверждение относится к различию между углом кастера и вертикальной линией (смотри рисунок выше), поэтому МЕНЬШИЙ кастер также означает более вертикальный угол. Одна и та же вещь, сказанная различными способами, но оба утверждения корректны. Поэтому, когда ваши приятели будут говорить о кастере, спросите их, что они подразумевают под «больше» или «меньше».
Крутой угол кастера (более вертикальный)
Увеличивает поворачиваемость при накате и торможении на входе в поворот.
Почему? Представьте, что угол кастера является вертикальным. Теперь представьте, что вы поворачиваете, колеса поворачиваются на сторону. Чем более вертикальный угол кастера, тем больше колеса отклоняются на сторону, обеспечивая вам более крутой заход в поворот.
Увеличивает эффективность подвески.
Почему? Внутренние шарниры подвески, для целей дискуссии, расположены параллельно шасси (горизонтально), это означает, что рычаги подвески перемещаются вверх и вниз вертикально. Теперь, представьте, что угол кастера вертикален, это означает, что ось поворота колеса параллельна направлению движения рычагов подвески. И наконец, допустим, что амортизаторы выровнены в вертикальной плоскости (верхняя часть не выступает вперед или назад относительно нижней части), расположены перпендикулярно продольной оси автомодели. Поскольку неровности на поверхности трассы вызывают вертикальное отклонение колес, чем более вертикально ориентирован узел поворота колес, тем лучше передняя подвеска поглощает ухабы без излишнего трения в подвеске.
Уменьшает поворачиваемость при ускорении на выходе из поворота.
Почему? Когда вы увеличиваете мощность на выходе из поворота, происходит перенос веса от передних колес к задним колесам. Чем более вертикален угол кастера, тем меньше эффективное изменение развала колес, поэтому ТОЛЬКО статический развал внешних колес определяет насколько хорошо колеса цепляются за поверхность. Поскольку колеса не могут эффективно цепляться за поверхность, снижение веса спереди вызывает более легкую потерю сцепления, вызывая недостаточную поворачиваемость автомодели.
Снижает самоцентрирование колес.
Почему? Представьте, что угол кастера вертикален. Теперь представьте, что вы держите передний край колеса и перемещаете его из стороны в сторону. Колесо отклоняется отклоняется пропорционально тому, как вы перемещаете его руками. Вертикальный кастер крайне нестабилен, так как отсутствует сила, которая принуждает колеса поддерживать прямое направление.
Пологий угол кастера (более наклонный) уменьшает поворачиваемость при накате и торможении на входе в поворот.
Почему? Представьте, что угол кастера настолько велик, что он является горизонтальным (хотя это невозможно). Теперь представьте, что вы поворачиваете, колеса не будут поворачивать на сторону, но скорее верхняя часть колес будет наклоняться из стороны в сторону. Чем больше наклонен угол кастера, тем меньше колеса отклоняются на сторону, обеспечивая менее крутой заход в поворот.
Увеличивает поворачиваемость при ускорении на выходе из поворота.
Почему? Чем больше наклонен угол кастера, тем больший эффективный развал вы получите, когда поворачиваете передние колеса. Когда вы увеличиваете мощность на выходе из поворота, происходит перенос веса от передних колес к задним колесам. Обычно это будет вызывать потерю сцепления передних колес и недостаточную поворачиваемость. Однако, поскольку присутствует больший эффективный развал из-за более наклонного угла кастера, «наклоненные» передние колеса могут более эффективно цепляться за поверхность, позволяя автомодели лучше сопротивляться центробежной силе, и обеспечивают большую величину контроля при выходе из поворота.
Увеличивает самоцентрирование колес, но снижает стабильность на прямых участках.
Почему? Представьте передние колеса магазинной тележки (которые обладают очень наклонным кастером).
Толкните тележку вперед, передние колеса будут всегда стремиться самоцентрироваться. Чем больше наклон угла кастера, тем больше рулевое управление будет стремиться вернуть себя в среднее положение. Однако, чем больше наклон угла кастера, тем больше величина силы, которая стремиться выровнять колеса. В конце концов, сила становится настолько большой, что колеса начнут вибрировать (колебаться), снижая стабильность на прямых участках.
Это еще не все
Однако, эти разъяснения не полностью описывают управляемость автомодели. Кастер сам по себе не определяет, как ваша автомодель управляется при накате, торможении и ускорении, но он определенно вносит свой вклад.
Управляемость автомодели является сложным взаимодействием множества факторов: кастер, развал, стабилизаторы поперечной устойчивости, амортизаторы и пружины — это только небольшой перечень. Поэтому, имейте в виду, что не существует одной «главной» настройки, которая позволит вашей автомодели управляться, как автомобиль «Formula 1», настройка автомодели является предметом компромиссов.
Поэтому, делайте небольшие регулировки по одной за один раз. Ваша магическая комбинация находится где-то там.
Автор статьи: Glenn Cauley.
Автор перевода: Владислав Ярополов.
Также немного материала из википедии и картинок из яндекса.
А что меня подтолкнуло на написание такого количества буков в блог — можете прочитать >>> тут 16 мая 2015 в 13:24
Реакция на аварию: растянутый кластер против DR-площадки
У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами). Они имеют несколько точек сохранения снэпшотов.
Запрос на катастрофоустойчивость есть, и многим нашим клиентам это реально нужно. Поэтому мы начали прорабатывать обе схемы в рамках нашего продакшна.
У методов есть плюсы и минусы, сейчас про них расскажу.
«Растянутый» кластер
Как видите, это стандартная история метрокластера. В плюсах — практически нулевой простой, пауза только на время запуска виртуальных машин. Отрабатывает такая фича — VMware High Availability (HA). Она видит, что хосты потерялись, и сразу же перезапускает ВМ на удалённой площадке.
Запуск делается сразу с СХД, которая находится в кластере.
СХД с геораспределённым кластером — это маркетинговая фича NetApp. У других производителей есть нечто с похожим названием. По сути, это продуманная асинхронная репликация с одной стороны на другую. Пишем на одну ноду в локальной сети и синхронизируем через специализированные каналы связи с другой.
В случае отказа одной из СХД оставшаяся (на другой площадке) презентует пути к дискам оставшимся же хостам. На них перезапускаются ВМ, которые погибли. Всё происходит автоматически — ЦОД грохнулся, всё перезагрузилось, СХД отработали, VMware отработала. Клиент увидел, что всё моргнуло и перезапустилось.
Единственное, кэш из оперативной памяти ВМ может потеряться. Но если база данных его скинула, то потеря нулевая по времени.
Если у нас теряется связь между площадками, то всё продолжает работать на своих местах и, как только связь восстанавливается, начинает синхронизироваться.
Минус — высокая цена. Потому что нужна фактически двойная СХД (причём аналогичная по типам, скорости и объёму дисков первой СХД на основной площадке), которую нельзя как-то использовать, кроме как под резерв. Плюс обвязка к СХД для метрокластера, это FC-бриджи, FC-сеть и прочее.
У нас два ЦОДа, между ними FC-связка по двум лучам (четыре линии тёмной оптики и DWDM). Это две железки, каждая обеспечивает по 200 Гбит пропускной способности для FC и Ethernet.
Альтернатива с DR
Есть софт с интуитивно запоминающимся названием — VMware vCloud Availability for Cloud-to-Cloud DR.
Это система создания идентичной ВМ на удалённой площадке раз, условно говоря, в 15 минут. К ней на изоленте примотана система презентации всего этого правильным образом в механизмы управления облаком.
То есть в бэкенде находится технология VMware Replication. В случае отказа мы вручную запускаем DR-план на второй площадке, он автоматически прекращает попытки реплицировать, затем регистрирует ВМ в vCloud Director, кастомизирует IP-адреса (чтобы не пришлось менять их на ВМ) и запускает ВМ в нужном порядке. В нашем решении менять адресацию не нужно, мы растягиваем сети на оба ЦОДа.
Машины реплицируются постоянно, но не весь ЦОД, а только выбранные — критичные процессы. Реплицируется раз в какое-то время, минимальный интервал — 15 минут (это идеальный случай, когда всё летает и есть выделенный сервер репликации и минимум изменений на ВМ). На практике у вас есть копия на полчаса или час назад. Если что-то пошло не так, то данные, которые попали в интервал, потерялись. 15 минут — это вопрос агента, который собирает новую репликацию. Veeam говорят, что могут меньше 15 минут, но по факту тоже на практике дольше, если не используют фичи СХД. Я не видел на промышленной машине (не на тесте), чтобы было иначе.
Уже давно у NetApp, как и у многих других производителей СХД, есть технология SnapMirror, которая позволяет переложить работу по репликации с гипервизоров на СХД, и VMware Replication умеет этим пользоваться.
Пока сервис репликации пробежит, поезд уходит далеко. Но зато это дёшево.
Почему ещё дёшево — потому что можно использовать любую СХД с любой стороны (от разных производителей, разного класса), не надо выделять заранее большой объём дисков.
Не надо выделять большую дисковую группу, внутри которой нарезаются луны. Просто берётся место на локальной СХД и применяется по факту наличия записи от виртуальной машины. За счёт этого оптимальнее занимается место на СХД, если она используется под другие задачи. А она используется, так как мы не всем клиентам даём такую услугу.
Минус — надо настраивать репликацию на уровне ВМ, то есть контролировать, что всё верно настроено, что это та машина, следить за тем, что репликация проходит, что ошибок нет. Создавать DR-планы для каждого клиента, проводить их испытания.
В первом случае СХД берётся, условно, инфраструктурно, чуть ли не по секторам (точнее, по объектам). А тут одна машина может отвалиться по причине отваливания задачи из-за каких-то софтверных причин, связанных с багом на высоких уровнях, или из-за проблем с доступностью. Это случается чуть чаще, чем если брать именно низкие уровни.
В плюсе — DR хранит несколько точек. Можно откатиться на несколько снепшотов назад.
Снаружи от гостевых ОС нужен дополнительный софт.
Чтобы до Vcloud Director прокинуть все нужные сети, нужна работа нашего администратора. Вообще, вся сетевая связность в этом варианте остаётся на нашем администраторе. Для клиента облака это означает заявку, что тоже занимает время.
Репликация настраивается тоже через заявку. Добавил ВМ — надо отправить заявку, что необходимо её реплицировать. Автоматом она в задачи по репликации не попадёт. Нужно уделять внимание админу.
Разница
В итоге цена может отличаться больше чем в два раза. Репликация будет умножать стоимость дискового пространства на два и больше (две полные копии + история изменений), плюс что-то за сервис и резервацию вычислительных ресурсов. В случае с метрокластером стоимость пространства будет умножаться на два, но само пространство будет стоить значительно дороже, плюс надо жёстко резервировать узлы на удалённой площадке. То есть и вычислительные ресурсы должны умножаться на два, мы их не можем утилизировать под что-то ещё.
В случае с метрокластером мы можем использовать только одинаковые типы дисков, чтобы было полное зеркало. Если на основном ЦОДе часть дисков быстрые, часть медленные на 10 тысяч оборотов в минуту, то нужна идентичная конфигурация. В случае реплики возможны более медленные диски на резервной площадке, а это дешевле за счёт хранения. Но при переключении на резерв он окажется по производительности меньше. То есть если он что-то хранит на SSD в основном кластере, а реплицируется на обычные диски, то хранение будет значительно дешевле ценой замедления инфраструктуры резерва.
Прямо сейчас мы выбираем то, что войдёт в более ранний релиз, поэтому хотим посоветоваться: можете коротко рассказать, как вы организуете свои DR-площадки и что бы от них хотели вообще в целом?
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂