Исправление ошибок клонирования виртуальных машин в облаке

Решение проблемы методом Runtime Image Activation

Преимущество виртуализации и виртуальных систем заключается в том, что их можно клонировать и многократно использовать в различных средах. Требования к подготовке внешних данных, таких как данные конфигурации сети типа IP-адресов, могут вызвать проблемы при клонировании виртуальной машины для использования в новой среде. Если во время процесса внешние данные недоступны, перенастройка виртуальной машины может оказаться неполной. Авторы предлагают способ решения этой проблемы без глубокого знания приложения и написания сценария активации. Runtime Image Activation (RIA) ― это прототип интерфейса командной строки, который позволяет согласовать сетевые методы, обеспечив надлежащую настройку клонированных ВМ.

Роберто Рагуза, штатный инженер-программист, IBM

Фото Роберто РагузыРоберто Рагуза (Roberto Ragusa) работает инженером-программистом в лаборатории интеллектуальных решений IBM в Риме. Он трудится над системой управления цифровыми ресурсами NICA (Networked Interactive Content Access). В его обязанности входит разработка и реализация проектов с использованием семилетнего опыта работы в области поиска документов, автоматической классификации, повышения производительности обработки на сервере и масштабируемости на платформах Linux и UNIX. Недавно написал быстродействующую поисковую систему на основе Lucene; любит работать с передовыми сетевыми технологиями.



Клаудио Маринелли, старший специалист, IBM

Клаудио МаринеллиКлаудио Маринелли (Claudio Marinelli) имеет 20-летний опыт работы в ИТ-индустрии и выполнял в IBM различные технические функции в рамках подразделения разработки программного обеспечения. В настоящее время ― старший специалист в IBM Tivoli. Как ведущий архитектор в области управления образами отвечает за систему управления жизненным циклом базового виртуального образа TPM for Images и компонент для автоматизации сборки и составления виртуальных образов ICON.



Луиджи Пикетти, старший специалист, IBM

Фото Луиджи ПикеттиЛуиджи Пикетти (Luigi Pichetti) ― старший специалист направления Tivoli в подразделении IBM/SWG. Имеет 20-летний опыт работы в ИТ-индустрии, главным образом в области разработки и архитектуры продуктов, компонентов и решений для управления системами и доставки услуг. В последнее время занимается управлением виртуализацией и облачными решениями; ведущий архитектур решений ISDM и IBM Cloudburst, а также средств доставки продуктов IBM на базе Image.



Алекс Донателли, заслуженный инженер, IBM

Алекс Донателли 's photoАлекс Донателли (Alex Donatelli) в 2008 году был номинирован на звание заслуженного инженера в области автоматизации служебных процессов. Инициатор технической стратегии создания таких ключевых продуктов, как Tivoli Provisioning Manager, Tivoli Endpoint Manager, Tivoli Scheduler и Tivoli Usage and Accounting Manager. В конце 2009 года возглавил группу Tivoli Performance Leadership и руководил работой по повышению производительности и масштабируемости семейства продуктов на базе Maximo и облачных вычислений.



09.01.2013

Одним из преимуществ использования образов виртуальных систем является возможность клонировать их, чтобы многократно использовать в различных средах. Обычно для этого требуются некоторые усилия по перенастройке программных приложений, содержащихся в образе. Широко известна проблема перенастройки при клонировании ВМ с предустановленным программным обеспечением, особенно при работе с приложениями, реализующими службы на стороне сервера (DBserver, AppServer и т.п.), которые могут не поддерживать DHCP и прослушивают входящие TCP-запросы по статическим адресам.

Для решения этой дилеммы реконфигурации образов существует процесс, называемый Image Re-Activation. Он использует такие методы, как применение механизма активации (такого как IBM Activation Engine, используемый для настройки виртуальных образов во время загрузки) и сценарии активации, зависящие от приложения. Проблема использования процесса Image Re-Activation в этих обстоятельствах заключается в том, что он предполагает, что для всех подлежащих настройке приложений имеется сценарий, выполнение которого приведет к правильной перенастройке.

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

Предлагаемый нами метод особенно полезен для возобновления работоспособности ВМ в тех случаях, когда в центре внимания находится решение проблем сетевой конфигурации стека программного обеспечения, создавшихся в результате клонирования ВМ. Этот подход не зависит от приложения; мы называем его Runtime Image Activation (RIA). Мы создали прототип интерфейса командной строки RIA, который позволяет планировать и осуществлять методы настройки конфигурации сети, описанные в этой статье ― решая проблему неправильной настройки при клонировании.

Идеальное клонирование не всегда хорошо

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

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

  • неудачные попытки установления связи с сетевым сокетом;
  • неудачные попытки связаться с необходимой сетевой службой;
  • появление дублирующихся IP-адресов в сети, несомненно вызовет, серьезные проблемы, такие как неожиданные сбои при установлении соединения, прерывание связи и общая нестабильность работы сети.

Сведения о том, на какие IP-адреса настроена машина, можно найти в файлах конфигурации операционной системы. Первый шаг, необходимый после клонирования виртуальной машины, ― замена IP-адресов. Эту задачу можно автоматизировать с помощью сценариев и инструментов, работающих непосредственно с содержимым образа времени выполнения, которые зависят от используемой операционной системы; например, они могут заменять строки в файлах /etc Linux®/ UNIX®-систем или вносить изменения в записи системного реестра Windows®.

Установленные приложения часто содержат некоторую внутреннюю конфигурацию, производную от конфигурации сети и перенесенную во время установки; например, Web-сервер может сохранить что-то в своих собственных данных конфигурации, например, IP-адрес или имя хоста, которые он будет указывать при выполнении запросов HTTP/HTTPS. Один из способов исправить это ― переустановить приложение; по существу, это будет означать переход от подхода клонирования предварительно настроенной машины к подходу установки машины с нуля. Это трудоемкий и неэффективный подход — теряются все преимущества клонирования, такие как возможность быстрого, надежного и согласованного создания виртуальных машин.

Каков же традиционный подход, позволяющий заново активировать программное обеспечение, содержащееся в ВМ, после их клонирования?


Традиционный подход: исправление всех настроек

Обычно эта задача решается хирургическим путем ― заменой неправильных настроек везде, где они могут находиться. В каждом случае это делается индивидуально. Можно представить себе работу, связанную с реализацией этого метода. Она требует точного знания присутствующих приложений и операций, которые нужно проделать с каждым из них. Эти операции могут выполняться в виде сценариев по отношению к смонтированному (не действующему) образу или на уровне агента первой загрузки в работающей машине.

При условии, что вы отлично знаете, что делать, конечный результат получается оптимальным: приложение ничем не отличается от того, которое просто «правильно» установлено.

С другой стороны, это очень деликатный метод; мелкие различия в деталях (например, «А вдруг пользователь изменил конфигурацию на другой путь?», «Вдруг эта версия программного обеспечения все еще использует то же хранилище конфигураций, что и прежняя?» и т.п.) превращает его в потенциальный ночной кошмар бухгалтера.

Попытки исправить конфигурацию без знания конкретного приложения обречены на провал. Сканирование всего образа и замену всех вхождений старых IP-адресов (в текстовой или двоичной форме) новыми никогда не следует рассматривать всерьез никому, кто знаком с законами Мерфи.

Есть стратегия получше... мы называем ее «игрой с сетевыми трюками».


Новая стратегия: сетевые трюки

Сейчас мы опишем альтернативный и инновационный подход к исправлению ошибок конфигурации клона без знания внутреннего программного обеспечения. Сначала определим сценарий:

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

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

Общая идея

Весь процесс описан на рисунке 1.

Рисунок 1. Общее описание решения
Общее описание решения

Слева изображена первоначальная машина (машина-источник), которая клонируется с созданием машины, изображенной справа (целевая машина; оранжевая точка 1). На момент клонирования внутри исходной машины установлены три приложения. Предположим, что приложение app1 может автоматически обнаруживать IP-адреса, назначенные машине, но приложения app2 и app3 используют IP-адреса, сохраненные в их собственных файлах конфигурации (текстовых или базах данных).

Проблема целевой машины состоит в том, что после замены старого IP-адреса (IPS) на новый (IPT; см. оранжевую точку 2) внешние клиенты могут обращаться только к app1; app2 и app3 недоступны, потому что они не смогли запуститься из-за ошибки при попытке установить связь с адресом IPS.

Что делать?

Дополнительный, фиктивный сетевой интерфейс

Для начала создадим дополнительный сетевой интерфейс; в Linux можно создавать сколько угодно псевдонимов интерфейса. Например, можно создать дополнительные интерфейс обратной связи (в дополнение к обычному lo, настроенному на 127.0.0.1/8) и присвоить ему старый IP-адрес (см. оранжевую точку 3 на рисунке 1). Дополнительный интерфейс можно сгенерировать как псевдоним lo, и он будет называться lo:0. Иначе, можно сгенерировать eth0:0, псевдоним устройства eth0.

Неправильно настроенное приложение сможет запуститься и установить связь с этим фиктивным интерфейсом. Принимать соединения с внешними машинами по-прежнему невозможно; мы ожидаем, что внешние хосты будут пытаться использовать новый IP-адрес, поэтому пакеты будут достигать нашей клонированной машины и немедленно отбрасываться, поскольку процесс не прослушивает интерфейс с новым IP-адресом.

На рисунке 2 указан новый адрес (IPT) 192.168.31.9 и старый адрес (IPS) 10.10.9.9.

Рисунок 2. Сервер запускается и устанавливает связь с фиктивным адресом
Сервер запускается и устанавливает связь с фиктивным адресом

Имеется демон, который смог запуститься, привязавшись к старому, «неправильному» IP-адресу.

Далее рассмотрим возможность переадресации с помощью трансляции сетевых адресов (Network Address Translation – NAT) на уровне ядра.

NAT-переадресация на уровне ядра

В качестве второго шага заставим операционную систему перехватывать все входящие соединения с новым IP-адресом и автоматически перенаправлять их на старый IP-адрес (да, это не опечатка: перенаправить НОВЫЙ адрес на СТАРЫЙ).

Такую переадресацию легко выполнить на уровне ядра с помощью правила трансляции сетевых адресов; NAT-переадресация не окажет заметного влияния на производительность, так как это просто хорошо известный трюк, используемый межсетевыми экранами и шлюзами. Эту задачу решает брокер соединений (оранжевая звезда на рисунке 1).

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

И последнее: нужно перенаправить только определенные порты.

Сторожевой демон, обеспечивающий NAT

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

Так как мы хотим обойтись без знания конкретных приложений (по сути, мы даже не хотим знать, какие именно приложения мы пытаемся исправить), нам нужно определить используемые порты автоматически. Для этого запросим у операционной системы список портов, которые кто-то прослушивает через интерфейс со старым IP-адресом.

В Linux этот список можно получить с помощью параметра netstat -l; организуем переадресацию NAT для этих портов.

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

Сторожевой демон (оранжевые точки 4 и 5 на рисунке 1) выполняет функции сканирования и управляет брокером.

Сторожевой демон в действии показан на рисунках 3 и 4.

Рисунок 3. Сторожевой демон в действии ― создание правила переадресации
Сторожевой демон в действии ― создание правила переадресации

Как видите, сторожевой демон обнаружил, что кто-то прослушивает адрес 10.10.9.9:80, и создал правило переадресации для прозрачного перенаправления трафика к 192.168.31.9:80 на адрес 10.10.9.9:80.

Рисунок 4. Клиент успешно устанавливает соединение
Клиент успешно устанавливает соединение

Теперь внешний клиент может подключиться к серверу, указав адрес 192.168.31.9:

  • с точки зрения клиента машина имеет новый адрес (192.*);
  • с точки зрения сервера у машины остался старый адрес (10.*), и он может обслуживать входящие сетевые запросы как до клонирования ВМ.

Итак, предлагаемый подход состоит в следующем:

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

Старый IP-адрес не виден внешним клиентам, которые ожидают, что сервер правильно настроен на новый IP-адрес. Демоны работают, устанавливая связь как с новым IP-адресом, так и со старым благодаря трюку NAT, проделываемому операционной системой.

Но есть еще несколько трюков реконфигурации, которые можно проделать, чтобы сделать решение более полным.


Дополнение стратегии: трюки с настройками

Хотя описанный механизм фиктивных IP-адресов решает большинство наших проблем, существует другие трюки с настройками, которые можно использовать для достижения более полного решения:

  • ARP-фильтрация (ARP ― это Address Resolution Protocol - протокол разрешения адресов);
  • разрешение имен и DNS-прокси;
  • ловушка getHostName().

ARP-фильтрация

Настройка фиктивных интерфейсов на Linux-машинах может иметь неприятный побочный эффект. Даже если это локальный фиктивный интерфейс (lo:0 вместо eth0:0), ответы на ARP-запросы по умолчанию передаются по любому интерфейсу для всех IP-адресов, присвоенных любому интерфейсу машины.

Это означает, что фиктивный IP-адрес является в некотором роде видимым для клиентов (и дает отклик на запрос при проверке достижимости). Желательно идеально скрытая работа, особенно, если нужно создать несколько клонов или копий исходной машины в одном и том же сегменте сети.

В Linux это можно сделать, изменив значение параметра arp_ignore сети sysctl на 1, чтобы избежать поведения по умолчанию (0 соответствует ответу на все ARP-запросы).

Разрешение имен и DNS-прокси

В том случае, если демоны app2/app3, изображенные на рисунке 1 для клонированной VM, сохраняют статическую ссылку на старое имя хоста (скажем, HNS), то вместе со старым IP-адресом (IPS) или вместо него нужно изменить цепочку разрешения имен, чтобы возвращался правильный IP-адрес.

Для этого достаточно отредактировать локальный файл конфигурации /etc/hosts таким образом, чтобы любой запрос к старому имени хоста (HNS) возвращал новый IP-адрес (IPT). Если в процессе разрешения имен используется внешний сервер имен, то можно установить локальный прокси-сервер DNS, настроенный как первый сервер имен в цепи с правом ответа, который будет отвечать в соответствии с измененным файлом /etc/hosts.

Использование ловушки getHostName()

Дополнительная стратегия настройки, которая может оказаться удобной, представляет собой «перехват» — захват вызова функции — из функции getHostName() таким образом, чтобы возвращались измененные значения (другими словами, старое имя хоста).

Это опробовано и может применяться для пользователей разных уровней (например, root-wide или для работы с процессами, запущенными со специальными и более низкими привилегиями пользователя).

Обобщение

Чтобы облегчить общий процесс настройки, предлагается опробованная командная строка RIA для Linux, которая позволяет применять методы настройки, описанные в этой статье.

Вот ее синтаксис и пример применения в виртуальной системе RHEL:

./ria start -oh <oldhostname> -oi <old_ipv4> -ni <new_ipv4> [options]
./ria stop | status

./ria start -oh oldhostname.domain.com -oi 10.10.1.1 -ni 1.2.3.4 -ipalias -hnresolv -dnat

Заключение

Практическое применение этой техники оказалась весьма успешным. Мы проверили ее на Web-сервере (Apache) и серверах приложений (IBM WebSphere® Application Server), которые нужно было установить со статической конфигурацией IP-адресов и которые после клонирования ВМ не работали бы ввиду того, что стек программного обеспечения по-прежнему пытается устанавливать связь, прослушивать или принимать старую конфигурацию IP-адресов, хранящуюся в артефактах настройки, зависящих от приложения.

Подход RIA позволяет обойти эту проблему, предоставляя стеку ПО сервера возможность работать в новой среде, хотя он "думает", что остается в старой. Этот подход требует регрессии вариантов использования основного продукта.

Имейте в виду, что подход Image Re-Activation всегда остается жизнеспособной альтернативой, стоящей изучения; это «хирургический» и четко выраженный подход, цель которого ― «удалить» старую конфигурацию приложения и заменить ее новой. Он может оказаться дорогостоящим, и иногда это не лучший подход.

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

Одно из возражений, которые могут выдвинуть пользователи: Что происходит в те секунды, когда приложение запущено, но демон NAT еще не организовал переадресацию?

Ответ: служба просто кажется недоступной для внешних клиентов; с их точки зрения служба успешно запускается только спустя несколько секунд. И никаких заметных негативных последствий при использовании разумного времени опроса, например, раз в секунду в течение нескольких минут (чтобы быстро зафиксировать запуск), а затем раз в 5-10 секунд.

Метод Runtime Image Activation легко встроить в ПО инициализации образов в облаке, и он был успешно проверен с применением стека Tivoli® Cloud Management (Tivoli Service Automation Manager, TSAM). Единственный элемент, который необходим для применения этого подхода в процессе развертывания виртуальных машин, ― это знание старых IP-адресов (которые можно указать при импортировании и регистрации образов в инструменте развертывания образов в облаке) и новых IP-адресов (которые инструмент развертывания образов в облаке динамически создает и использует в соответствующих рабочих процессах развертывания).

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Linux
ArticleID=854360
ArticleTitle=Исправление ошибок клонирования виртуальных машин в облаке
publish-date=01092013