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

Календарь мероприятий
март    2019
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
24
30
31

показать все 

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

19.03.2019

II Международный бизнес-форум «ИГРЫ XXI ВЕКА»

Читать далее 

18.03.2019

Конференция «Весенний документооборот»

Читать далее 

18.03.2019

HID Global продемонстрирует инновационные продукты и решения в области физической безопасности и надежной идентификации на выставке Securika Moscow 2019

Читать далее 

15.03.2019

Началась продажа билетов на конференцию «Инновации для корпораций–2019»

Читать далее 

15.03.2019

Тему кибербезопасности обсудят на РИФ+КИБ 2019

Читать далее 

15.03.2019

Забег RUNIT 25 на РИФ+КИБ 2019

Читать далее 

14.03.2019

Конференция «E.DAY 2019. Встраиваемые Технологии и Интернет Вещей»

Читать далее 

показать все 

Статьи

12.03.2019

Тренды по UC

Читать далее 

25.02.2019

Корневые причины неудач. Значимость бизнес-процессов в достижении целей организации

Читать далее 

25.02.2019

Зачем нам 5G?

Читать далее 

25.02.2019

Продвигаем ИТ-продукты/услуги

Читать далее 

25.02.2019

Какую модель выбрать?

Читать далее 

25.02.2019

Держим ушки на макушке?

Читать далее 

21.04.2017

Язык цифр или внутренний голос?

Читать далее 

16.04.2017

Планы – ничто, планирование – все. Только 22% компаний довольны своими инструментами для бизнес-планирования

Читать далее 

16.04.2017

Цифровизация экономики

Читать далее 

23.03.2017

Сервисная компания – фея или Золушка?

Читать далее 

показать все 

Виртуализация бизнес-критичных систем на базе 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 (85) 2019г.
Выпуск №02 (85) 2019г. Выпуск №01 (84) 2019г.
Вакансии на сайте Jooble

           

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

 

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

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