Kir Kolyshkin Голосов: 1 Адрес блога: http://k001.livejournal.com/ Добавлен: 2008-02-19 12:45:30 блограйдером Lurk

My tweets

2012-07-01 12:00:22 (читать в оригинале)

• Sun, 10:12: RT @tishkinda: Мостик в усть ухте http://t.co/Y1zZTbKh

---

My tweets

2012-06-30 12:00:23 (читать в оригинале)

• Fri, 16:27: #OpenVZ vzubc tool: better cat /proc/user_beancounters http://t.co/PI9GDoBk
• Fri, 20:49: :))) RT @vashurkov: Обсуждал с @navalny сравнительные преимущества Ruby on Rails и PHP. К согласию не пришли
• Fri, 21:46: Потому что мало приносят, 5 минут и ты без фруктов RT @kirillkokorin: Когда на работе приносят фрукты, народ сразу подрывается с места...
• Fri, 21:49: #большеада RT @RT_russian: Пресс-секретарь движения "Наши": активистка Светлана Курицына ("Света из Иваново") станет ведущей ток-шоу на НТВ
• Fri, 21:51: #большеада в ленте! RT @zaharrra: отправляю открытку тайваньской девушке с именем Hui-li #postcrossing
• Fri, 21:52: #большеада RT @nastyacoyote: ААА, это бомба вообще. "@prativaves: акция #стопкал http://t.co/sExbTqzB "

---

вопросы к Parallels/Протасову на Хабре

2012-06-20 16:32:49 (читать в оригинале)

Почти год назад, в прошлом августе, Стас Протасов (это главный человек в московском офисе Parallels, сооснователь компании и глава всей разработки) отвечал на вопросы аудитории сайта linux.org.ru (он же ЛОР). Я в этом процессе немножко участвовал, и на мой взгляд, получилось очень даже нехреново, лучше, чем я ожидал.

Я тогда ничего не сказал, а сейчас скажу. Получилось бы много лучше, если бы ЛОР-админы не зарезали половину вопросов (и, соответственно, ответов Стаса -- они уже были готовы) с формулировкой "а то все подумают, что на ЛОРе одни придурки" (или что-то в этом духе). Зарезанные вопросы были в лучших традициях старой школы троллинга, но так как Стас сам тролль 80 уровня, он ответил на них весьма остроумно.

Так вот, сейчас примерно то же самое делает сайт habrahabr.ru. Я очень надеюсь, что и сами вопросы будут лучше, и администрация сайта не станет их перлюстрировать.

Поэтому, если у вас есть что спросить у Parallels и/или Стаса Протасова, пройдите, пожалуйста, вот сюда, там пока собирают вопросы.

---

how to boot floppy disk and CD disk images using grub and grub2

2012-06-07 16:25:46 (читать в оригинале)

I spend about an hour fiddling with this stuff yesterday, so I think it might be worth sharing my findings.

Using the below instructions, you can easily boot floopy and ISO images, such as the ones used for hardware diagnostics, right from GRUB or GRUB2 bootloader. That eliminates the need to write a CD or run around searching for a strange thing called a floppy drive (I hear nowadays the best person to ask is a musician).

1 Take 'memdisk' binary from syslinux (in Fedora: yum install syslinux) and put it to /boot (in Fedora: cp /usr/share/syslinux/memdisk /boot).

2 Put your floppy image or iso image to /boot. I am using Drive Fitness Test, and succeeded with both floppy (.IMG) and CD (.ISO) image.

3 This step depends of whether you have GRUB or GRUB2.

3.1 For GRUB, add the following to /boot/grub/grub.cfg:

# for ISO
title DFT iso image
      kernel /memdisk iso
      initrd /your-image.iso

# for floppy
title DFT floppy image
      kernel /memdisk
      initrd /your-image.img

3.2 For GRUB2, add this to /etc/grub.d/40_dft:

#!/bin/sh

cat << EOF
# for ISO
menuentry "DFT ISO image" {
      kernel16 /memdisk iso
      initrd16 /your-image.iso
}

# for floppy
menuentry "DFT floppy image" {
      kernel16 /memdisk
      initrd16 /your-image.img
}
EOF

4 For more info, see memdisk docs

---

Эффективная живая миграция с ploop write tracker

2012-05-31 02:03:00 (читать в оригинале)

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

Я тут недавно отдыхал на солнечном побережье гостеприимной Турции, и по ночам, вместо того, чтобы дегустировать спиртные напитки или отдыхать после утомительного дня на пляже, в холле отеля, где работал вайфай, доделывал (и доделал) миграцию контейнеров на пилупе. Для любознательных, это почти все коммиты в ploop вот отсюда и ещё верхние 14 коммитов в vzctl вот отсюда. Хочу рассказать про весь этот функционал.

Начну издалека, а именно с того, как вообще реализована миграция, то есть перенос контейнера с одного OpenVZ сервера на другой. Команда vzmigrate -- это скрипт на шелле, он обычно делает следующее (упрощённо):
1. Проверяет, что можно попасть на другой сервер по ssh без пароля, и что там нет контейнера с таким CTID, и что-то ещё в том же духе.
2. Делает rsync /vz/private/$CTID на другой сервер
3. Останавливает контейнер
4. Делает второй rsync /vz/private/$CTID на другой сервер
5. Запускает контейнер на другом сервере
6. Удаляет его локально.

Два запуска rsync нужны для того, чтобы первый перенёс большинство данных, пока контейнер всё ещё работает, а второй -- перенёс то, что изменилось за время между работой первого и стопом контейнера.

Теперь, если нам нужна живая миграция (это опция --online для vzmigrate), то (опять слегка упрощённо) вместо стопа делается vzctl chkpnt, а вместо старта -- vzctl restore. Результат -- ваш контейнер переехал, а пользователи ничего не заметили (процессы не останавливаются, а всего лишь "замирают" на несколько секунд, TCP-соединения тоже переезжают, IP не меняется и т.п., в общем, немножко магии и никакого мошенничества).

Таким примерно образом всё это работало, и все были довольны. А потом появился ploop, и выяснилось, что миграция с ploop не работает. Нашлось даже несколько причин, почему (например, для копирования образов ploop нельзя использовать --sparse, потому что ploop не умеет работать с файлами, в которых есть "дырки"). Но главное, что в процессе разбора выяснилось, как правильно мигрировать ploop: не через rsync, а с помощью ploop copy.

ploop copy -- это механизм эффективного копирования образа ploop с использованием встроенного в ploop механизма слежения за записью (write tracker). Один процесс ploop copy вычитывает с диска блоки данных образа и пишет их в stdout (предваряя каждый блок маленьким заголовочком из метки, позиции блока на диске и его размером), то есть в "трубу", а второй процесс читает их из stdin и скидывает на диск. Добавляем между ними ssh $DEST, и вуаля.

Скажете, что почти то же самое и cat умеет делать. Разница в том, что перед тем, как начать передавать данные, ploop copy просит у ядра включить write tracker, и ядро начинает запоминать блоки данных, в которые пишут. После того, как все блоки переданы, ploop copy вежливо интересуется у ядра списком модифицированных блоков, и передаёт их снова, а ядро в это время составляет новый список. Процесс повторяется несколько раз, и список блоков становится всё меньше и меньше. Через какое-то количество итераций (или этот список становится пустым, или перестаёт уменьшаться, или просто мы решаем, что уже случилось слишком много итераций) ploop copy запускает некую внешнюю команду, которая должна вызвать прекращение всякой дисковой активности контейнера. Команда эта vzctl stop для миграции обычной, или vzctl chkpnt для "живой"; действительно, остановленный или замороженный контейнер на диск писать уже ничего не может. После этого мы ещё раз спрашиваем у ядра список модифицированных блоков и передаём их в трубу, потом ещё раз спрашиваем и убеждаемся, что список пуст (а иначе "прекращающая" команда не сработала и всё пропало), и посылаем в трубу признак конца передачи. Вот так устроен передающий процесс.

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

Так вот, в вышеприведённой схеме миграции ploop copy используется вместо второго rsync (пункты 3 и 4). Замечу, что это гораздо эффективнее, потому как rsync пытается понять, какие файлы изменились и в чём, а ploop copy просто спрашивает про это у ядра, причём поскольку процесс "спросили-скопировали" итеративный, контейнер останавливается или замораживается как можно позже и, даже если контейнер активно пишет на диск, период времени, когда он остановлен, минимален.

Я ради интереса сделал простой и ненаучный тест, запустив od -x /dev/urandom > file в контейнере и помигрировав его туда-сюда. Получил время ploop copy после запуска стоп-команды чуть больше секунды, а общее время, пока контейнер был заморожен -- чуть меньше трёх секунд. Примерно такие же цифры получается для simfs с rsync, но только если контейнер ничего не делает. А если такой же мигрировать, с "писателем" внутри, то время сразу увеличивается до 13-16 секунд. Не претендую на точность измерений, мерял как попало, OpenVZ стояла внутри параллельских VMок, на ноде что-то ещё делали...

И последнее. Всё это доступно сейчас только из гита (клонируйте, собирайте, пробуйте) и будет включено в релиз ploop-1.3 и vzctl-3.3.