Что происходит при сбое физической машины в виртуальной среде? [закрыто]
12
Я начинаю с виртуализации, так что терпите меня.
В виртуальных средах приложения работают на уровне гипервизора. Таким образом, на одной физической машине может быть много виртуальных машин, на которых выполняются несколько приложений.
Все идет нормально?
Так что же происходит, когда отказывает физическая машина? Не приведет ли это к тому, что многие приложения потерпят неудачу на одной машине?
Я ищу разработку частного облака с OpenStack , но сначала я хочу полностью понять виртуализацию.
Специфика зависит от того, какое именно решение для виртуализации вы используете, но идея заключается в том, что у вас есть виртуальная ферма, в которой есть несколько физических хостов с несколькими виртуальными машинами в каждой. Затем вы используете некоторую эффективность, которую вы получили, не нуждаясь в физическом хосте для каждой виртуальной машины, чтобы у вас оставалось достаточно ресурсов для покрытия в случае сбоя физической машины.
Кроме того, вы можете найти VHD для каждой виртуальной машины в общей (избыточной) SAN. Гипервизоры на каждом физическом хосте могут быть настроены для общения друг с другом и совместного использования памяти различными виртуальными машинами. Существует некоторая задержка, и большая часть памяти будет поддержана диском, но если один из физических хостов выйдет из строя, вы даже не дождетесь, пока виртуальные машины с этого хоста загрузятся. Вместо этого эти виртуальные машины будут автоматически распределены среди оставшихся хостов. Конечная цель заключается в том, что эти машины будут забрать почти с того места, где они остановились, практически без простоев. В некотором смысле все ваши виртуальные машины уже работают как минимум на двух физических хостах. На практике, сейчас гипервизоры могут выполнять такую миграцию только по одной машине за раз, когда они знают, что она идет до того, как хост выйдет из строя ... но не делайте ошибку: мгновенная миграция при сбое оборудования является конечной целью для всех основных гипервизоров.
Вот почему иногда вы видите сервер, виртуализированный на одном физическом хосте в ферме. Вы не можете получить какую-либо аппаратную эффективность (вы можете даже потерять некоторую производительность), но вы восполняете ее с точки зрения согласованности управления и встроенной высокой доступности.
Спасибо за ваш ответ Джоэл ... У меня есть 2 вопроса ... Виртуальная среда рассматривает физические машины как единый пул ресурсов? это помогает удовлетворить самообслуживание по требованию? Также помогает ли использование ресурсов витуализации?
Шериф
1
@Sherif: В основном да и да. Если вы хотите понять это более подробно, взгляните на статью в Википедии , в которой кратко рассматриваются миграция и восстановление после отказа виртуальной машины. Если у вас остались вопросы, задайте более конкретный вопрос.
слеске
1
Вы уверены в части с общей памятью? Насколько я понимаю, сбой ВМ из-за аппаратного сбоя будет перезапущен на другом хосте. Это можно рассматривать как полную перезагрузку или восстановление контрольной точки, в зависимости от конфигурации гипервизора, но исходное состояние памяти восстановить невозможно. Для vspere: vmware.com/products/vsphere/features/high-availability В качестве дополнительного примечания, некоторые проекты были запущены для KVM, чтобы обеспечить истинно разделяемую избыточную память среди набора аппаратных узлов , но они были заброшены.
Shodanshok
1
Миграция виртуальной машины может произойти только в том случае, если физическая машина имеет возможность передать управление перед падением. Если физическая машина выходит из строя бесцеремонно, то виртуальную машину придется перезапустить на другой машине. Если у вас есть сервер без сохранения состояния, этот процесс переноса является тривиальным, потому что вы можете просто раскрутить другую машину. Для машин с постоянными состояниями вам необходимо иметь схему, которая может восстановить постоянные данные с неисправного физического компьютера.
Ли Райан
13
Все виртуальные серверы, работающие на физическом хосте, перейдут в автономный режим, если на хосте произойдет какой-либо сбой.
Тем не менее, большинство платформ предлагают решение высокой доступности для одной виртуальной машины. В других случаях система строится с несколькими узлами, чтобы предотвратить прерывание обслуживания в случае отказа одного узла.
Если два узла виртуальной машины составляют высокодоступную услугу, можно настроить гипервизор, чтобы гарантировать, что два узла не зависят от одной и той же физической инфраструктуры (отказоустойчивость). Это может быть больше, чем просто отказоустойчивость физического сервера, включая различные сетевые пути, вплоть до географически разнородного местоположения.
Например, AWS, в зависимости от сервиса, реплицирует сервис по зонам доступности (физическим областям) на случай, если в этой области произойдет стихийное бедствие, которое нарушит работу физических машин.
Майкл Бейли
виртуальная среда смотрит на физические машины как единый пул ресурсов? это помогает удовлетворить самообслуживание по требованию? Также помогает ли использование ресурсов витуализации? и большое спасибо за ваши усилия
Шериф
5
Вы правы, предполагая, что если физическая машина выходит из строя, виртуальные машины становятся недоступными.
Но openstack может позаботиться об этом и запустить виртуальные машины вышедшего из строя физического сервера на другом сервере, или вы можете использовать систему гипервизора, которая уже распределена, я думаю, vsphere может сделать это.
Что касается вашего вопроса - да, вы потеряете доступ ко всем машинам на этом физическом хосте. Конечно, это зависит от того, какой компонент вышел из строя. Если это диск - это своего рода проблема, если это материнская плата - это намного проще. В целом, восстановление оборудования проще, поскольку гипервизор не зависит от оборудования. На данный момент существует множество технологий, специфичных для разных поставщиков, которые можно использовать для предоставления высокодоступных услуг.
Resource Pools (vmware) - НЕ способны агрегировать несколько физических ресурсов хоста (процессор, память и т. Д.), Как кто-то упоминал выше, поэтому, если у вас есть 2 физических хоста (скажем, четырехъядерный процессор 1CPU без гиперпоточности - 8GBRAM каждый), это НЕ будет там можно установить виртуальную машину 5vCPU-12Gb. Пулы ресурсов являются логическими, они не способны создавать суперкомпьютерные системы. Прямо сейчас это способ контролировать использование ресурсов.
Доступность (vmware) - можно использовать технологии, такие как Высокая доступность (HA), которые позволяют автоматически (в зависимости от моего опыта в течение 1-2 минут ) автоматически восстанавливать все виртуальные машины в кластере, если вы используете Storage Array (NAS, iSCSI, FC) и храните все файлы VM там. Более того, HA работает только в случае отказа ЦП, ОЗУ, материнской платы, очевидно, он не будет работать из-за отказа Storage Array. Чтобы предотвратить сбои RAID / Controllers, люди используют репликацию, зеркальное отображение LUN и т. Д.
Если восстановление в течение 1-2 минут невозможно, существуют такие технологии, как Fault Tolerance (FT), которые позволяют достичь нулевого времени простоя ВМ в случае сбоя, сохраняя теневую (работающую) копию настроенной ВМ. Но эта технология также имеет множество ограничений - проблема отказоустойчивых виртуальных машин с несколькими виртуальными ЦП не решена полностью.
Все виртуальные серверы, работающие на физическом хосте, перейдут в автономный режим, если на хосте произойдет какой-либо сбой.
Тем не менее, большинство платформ предлагают решение высокой доступности для одной виртуальной машины. В других случаях система строится с несколькими узлами, чтобы предотвратить прерывание обслуживания в случае отказа одного узла.
Если два узла виртуальной машины составляют высокодоступную услугу, можно настроить гипервизор, чтобы гарантировать, что два узла не зависят от одной и той же физической инфраструктуры (отказоустойчивость). Это может быть больше, чем просто отказоустойчивость физического сервера, включая различные сетевые пути, вплоть до географически разнородного местоположения.
источник
Вы правы, предполагая, что если физическая машина выходит из строя, виртуальные машины становятся недоступными.
Но openstack может позаботиться об этом и запустить виртуальные машины вышедшего из строя физического сервера на другом сервере, или вы можете использовать систему гипервизора, которая уже распределена, я думаю, vsphere может сделать это.
Вы должны прочитать документацию openstack по HA для получения дополнительной информации.
источник
Что касается вашего вопроса - да, вы потеряете доступ ко всем машинам на этом физическом хосте. Конечно, это зависит от того, какой компонент вышел из строя. Если это диск - это своего рода проблема, если это материнская плата - это намного проще. В целом, восстановление оборудования проще, поскольку гипервизор не зависит от оборудования. На данный момент существует множество технологий, специфичных для разных поставщиков, которые можно использовать для предоставления высокодоступных услуг.
Resource Pools (vmware) - НЕ способны агрегировать несколько физических ресурсов хоста (процессор, память и т. Д.), Как кто-то упоминал выше, поэтому, если у вас есть 2 физических хоста (скажем, четырехъядерный процессор 1CPU без гиперпоточности - 8GBRAM каждый), это НЕ будет там можно установить виртуальную машину 5vCPU-12Gb. Пулы ресурсов являются логическими, они не способны создавать суперкомпьютерные системы. Прямо сейчас это способ контролировать использование ресурсов.
Доступность (vmware) - можно использовать технологии, такие как Высокая доступность (HA), которые позволяют автоматически (в зависимости от моего опыта в течение 1-2 минут ) автоматически восстанавливать все виртуальные машины в кластере, если вы используете Storage Array (NAS, iSCSI, FC) и храните все файлы VM там. Более того, HA работает только в случае отказа ЦП, ОЗУ, материнской платы, очевидно, он не будет работать из-за отказа Storage Array. Чтобы предотвратить сбои RAID / Controllers, люди используют репликацию, зеркальное отображение LUN и т. Д.
Если восстановление в течение 1-2 минут невозможно, существуют такие технологии, как Fault Tolerance (FT), которые позволяют достичь нулевого времени простоя ВМ в случае сбоя, сохраняя теневую (работающую) копию настроенной ВМ. Но эта технология также имеет множество ограничений - проблема отказоустойчивых виртуальных машин с несколькими виртуальными ЦП не решена полностью.
В целом, каждое решение зависит от вашей цели.
источник