Приветствую Хабр!

В данном небольшом how-to хотел бы поделиться с вами своим опытом использования утилиты lvmsync.

Данная утилита позволяет решить задачу переноса виртуальной машины с одного сервера KVM на другой, с минимальным простоем виртуальной машины, без использования общего хранилища (non-shared storadge).
Передавать мы будем весь раздел LVM, на который установлена виртуальная машина. Ну а уменьшить время простоя нам поможет магия работы LVM snapshot, информацию о которой вы с легкостью можете найти в интернете.

Вот как выглядит перенос виртуальной машины в кратком виде:

1. Делаем снимок LVM раздела.
2. Передаем основной LVM раздел по сети, не останавливая нашу VM.
3. Когда закончится передача основного раздела, останавливаем VM.
4. Запускаем lvmsync для передачи снимка по сети. Передается не весь снимок, а только измененные блоки.
5. Подготавливаем и запускаем VM на новом сервере.

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

Подробнее о работе lvmsync, и дополнительных плюшках вы можете почитать на страничке проекта.

Введение

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

Измерить качество обслуживания напрямую мы, конечно, не можем, однако даже такую эфемерную величину в принципе можно свести к набору количественных характеристик, так или иначе косвенно отражающихся на качестве. Прибыль, число клиентов, процент конвертированных лидов (leads – зарегистрировавшиеся или заинтересованные пользователи) и т.д. – все это вполне объективные показатели. Кроме того, эти величины могут быть включены в систему контроля эффективности работы в качестве KPI – ключевых показателей эффективности.

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

Анализ отклика и HTTP-кодов удобно проводить на основе некоторой собранной статистической базы, и здесь мы плавно подходим к теме статьи.

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

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

Задача которую нужно было решать — каким образом хранить, искать, модифицировать информацию о последовательности событий при следующих условиях:

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

Последние два пункта очень важны для бизнеса и просто жизненно важны для опс инженеров если они хотят спокойно выполнять свои обязанности днём, и спокойно спать ночью.