Виртуализация бизнес-критичных систем на базе RHEL6::БИТ 01.2012
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
апрель    2024
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

показать все 

Новости партнеров

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

показать все 

Статьи

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Виртуализация бизнес-критичных систем на базе RHEL6

Главная / Архив номеров / 2012 / Выпуск №1 (14) / Виртуализация бизнес-критичных систем на базе RHEL6

Рубрика: Виртуализация


 Оксана Курышеваинженер, RHCSA. Работает в НЦПР, участвует в проектах по виртуализации Red Hat

Виртуализация бизнес-критичных систем
на базе RHEL6

Почти в каждой организации часть задач работает в виртуальной среде. Но когда речь заходит о критичных для бизнеса приложениях, обычно их предпочитают оставить работать «как есть», то есть «на чистом железе». Почему? Просто из соображений «а вдруг оно как-нибудь не так себя поведет» – всем хочется спать спокойно

Откуда берутся эти сомнения? Ведь сколько говорили, что приложение вообще не отличает виртуальную машину от физического сервера. В серьезных системах виртуализации разных вендоров есть механизмы обеспечения отказоустойчивости. Но нет – все равно виртуализировать критичные задачи как-то неуютно.

Если разобраться в причинах, то выясняется, что большинство сомнений вызваны в основном управлением ресурсами в виртуальных средах. Всегда ли критичная система в виртуальной среде получит нужные ей процессорное время, память, пропускную способность сети и диска? Что случится, если виртуальных машин много, и ресурсов хотят они все?

Навскидку совершенно неочевидно, насколько можно в такой ситуации гарантировать качество обслуживания (quality of service, QoS) для нагруженных критичных виртуальных машин.

Однако перенести в виртуальную среду, в том числе критичные и нагруженные системы, вполне реально. Это мы проверим на базе Red Hat Enterprise Linux 6 и входящего в его состав гипервизора KVM. Необходимый нам для решения задачи инструмент называется Cgroups [1, 3].

Он позволяет тонко управлять всеми основными ресурсами системы – процессорным временем, оперативной памятью, пропускной способностью дисков и сети. За счет этого становится возможным обеспечить необходимое качество обслуживания для критичных задач.

Модельный ночной кошмар системного администратора представлен на рис. 1.

Рисунок 1. Виртуальные машины на базе KVM. Результаты без использования Cgroups. Есть риск, что критичная задача не получит нужных ресурсов из-за пересечения со второстепенной

Рисунок 1. Виртуальные машины на базе KVM. Результаты без использования Cgroups. Есть риск, что критичная задача не получит нужных ресурсов из-за пересечения со второстепенной

Существует критичная для бизнеса система, которая постоянно анализирует достаточно большие объемы данных и питает ими другие приложения. Если она работает медленно, начинается цепная реакция, и постепенно рушатся смежные системы.

Система развернута в виртуальной машине. Виртуальная машина постоянно обращается к диску, именно от скорости чтения данных в первую очередь зависит качество работы всей системы. Что случится, если виртуальная машина, в которой работает наша критичная система, случайно окажется на одном физическом сервере с другой виртуальной машиной, в которой работает система второстепенная, но ничуть не менее требовательная к диску?

Точный ответ зависит от многих нюансов, но скорее всего ничего хорошего не получится. На рис.1 показана ситуация, когда в какой-то момент второстепенная виртуальная машина начинает активно обращаться к диску, в результате чего производительность критичной системы заметно страдает. И страшен даже не сам факт, что она вообще уменьшается, а то, что она уменьшается непредсказуемо.

На рис. 2 показана та же система, что в первом примере, и под той же нагрузкой, но уже после настройки Cgroups. Видно, что теперь второстепенная виртуальная машина значительно ограничена в доступных ресурсах, ее активность не вызывает резкого падения производительности критичной системы.

Разумеется, данный пример весьма ограничен – в нем присутствует всего две машины и рассматривается только пропускная способность диска (частое «узкое место» и самый неочевидный в управлении ресурс).

Рисунок 2. Виртуальные машины на базе KVM. Результаты с использованием Cgroups. Тонкое управление ресурсами позволяет обеспечить необходимое качество обслуживания

Рисунок 2. Виртуальные машины на базе KVM. Результаты с использованием Cgroups. Тонкое управление ресурсами позволяет обеспечить необходимое качество обслуживания

Кроме того, для гибкого управления ресурсами в виртуальной системе большого масштаба необходимо учитывать, помимо Cgroups, и другие механизмы, такие как динамическое изменение объема оперативной памяти (ballooning) и возможность живой миграции виртуальных машин между физическими серверами для балансировки нагрузки.

Более полная картина, как Cgroups работают в сочетании с другими технологиями, будет рассмотрена в последующих статьях.

Тем не менее уже сейчас основных источников информации по настройке [2, 4, 5] должно вполне хватить для начала работы с Cgroups и для повторения приведенных результатов тестов.

Дополнительно стоит отметить, что Cgroups не специфичны именно для задач виртуализации и могут применяться для управления ресурсами любых групп процессов в системе.

  1. Cgroups в Википедии (на английском) – http://en.wikipedia.org/wiki/Cgroups.
  2. Полное руководство по управлению ресурсами с помощью Cgroups в RHEL6 (на английском) – http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide.
  3. Cgroups в документации ядра (на английском) – http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt.
  4. Краткая инструкция по началу работы с Cgroups (на русском) – http://www.ossportal.ru/technologies/kvm/blogs/422.
  5. Цикл статей о виртуализации на базе KVM и управлении ресурсами в ней (на русском) – http://www.ossportal.ru/technologies/kvm.

В начало⇑

 

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №02 (135) 2024г.
Выпуск №02 (135) 2024г. Выпуск №01 (134) 2024г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика