Sunday, 31 October 2010
Веб-интерфейсы для Bind
1. CyberDNS http://freshmeat.net/projects/cyberdns (Python, Django)
2. ISPSystems DNSManager http://ispsystem.com/en/software/dnsmanager/
Вот еще целый набор: http://www.debianadmin.com/bind-dns-server-web-interfacefrontend-or-gui-tools.html
2. ISPSystems DNSManager http://ispsystem.com/en/software/dnsmanager/
Вот еще целый набор: http://www.debianadmin.com/bind-dns-server-web-interfacefrontend-or-gui-tools.html
Как удалить splash boot в Fedora?
Нужно открыть /etc/grub.conf и у строки kernel в самом конце удалить строки
rhgb quiet
Переключение Apache на Debian 5 Lenny в режим worker MPM
Итак, имеем Апача, работающего в режиме prefork с подключенным php5 как модулем Апача. Вариант миграции на Apache MPM worker только один - отказываться от php5 как модуля Апача и переходить на php5 как FastCGI (посредством mod_fcgid). Я рассмотрю лишь подключение Apache Worker, с mod_fcgid Вам придется разобраться самостоятельно.
Итак, имеем следующую конфигурацию Апача:
Итак, пробуем ставить Apache worker:
В ответ APT выдаст предупреждение о том, что в связи с конфликтом нужно удалить следующие пакеты: apache2-mpm-prefork и libapache2-mod-php5. Соглашаемся с этим. После этого APT сделает попытку перезапустить Апача, но, скорее всего, ему это не удастся, так как все было настроено для php5 как модуля Апача и в конфигурации много директив php_admin_value, которые уже некем обрабатывать (модуль-то Апача мы стерли):
Удаляем эти конфиги / директивы и повторяем попытку перезапуска Апача:
Все, после этого все должно заработать как нужно :)
Убеждаемся, что мы работаем на Worker MPM:
Итак, имеем следующую конфигурацию Апача:
dpkg -l | grep prefork
ii apache2-mpm-prefork 2.2.9-10+lenny8 Apache HTTP Server - traditional non-threaded model
Итак, пробуем ставить Apache worker:
apt-get install apache2-mpm-worker
В ответ APT выдаст предупреждение о том, что в связи с конфликтом нужно удалить следующие пакеты: apache2-mpm-prefork и libapache2-mod-php5. Соглашаемся с этим. После этого APT сделает попытку перезапустить Апача, но, скорее всего, ему это не удастся, так как все было настроено для php5 как модуля Апача и в конфигурации много директив php_admin_value, которые уже некем обрабатывать (модуль-то Апача мы стерли):
Syntax error on line 7 of /etc/apache2/conf.d/phpmyadmin.conf:
Invalid command 'php_admin_value', perhaps misspelled or defined by a module not included in the server configuration
failed!
Удаляем эти конфиги / директивы и повторяем попытку перезапуска Апача:
/etc/init.d/apache2 restart
Все, после этого все должно заработать как нужно :)
Убеждаемся, что мы работаем на Worker MPM:
apache2ctl -M 2>&1| grep mpm
mpm_worker_module (static)
Saturday, 30 October 2010
Показать время, затраченное на MySQL запросы в wordpress
Можно плагином: WP MySQL Profiler
Миграция с MySQL 5.0 на MySQL 5.1 (Debian)
Итак, у нас имеется /var/lib/mysql от mysql 5.0 (5.0.8x-percona-bxx), а также работающий сервер с MySQL 5.1 (5.1.5x Percona Server). Задача - корректно перенести все данные на 5.1.
Для начала просто положим папку /var/lib/mysql от 5.0 в соответствующую папку от 5.1. Далее прежде чем запустить СУБД обратим внимание на то, что в Debian есть такой прекрасный скрипт как /etc/mysql/debian-start, который делает ряд нужных нам задач: upgrade_system_tables_if_necessary (апгрейд таблиц, нам как раз и нужна эта фича, она запускает скрипт /usr/bin/mysql_upgrade, которая, во-первых, обновляет структуру самих таблиц, а, во-вторых, вносит изменения в системные таблицы), check_root_accounts, check_for_crashed_tables (проверка всех MyISAM таблиц на консистентость). Но для работы этому скрипту нужны доступы к mysql с root привилегиями, которые обеспечиваются файлом /etc/mysql/debian.cnf, который необходимо перенести со старой машины (либо просто руками скопировать root пароль).
После этой подготовки запускаем СУБД и около получаса-часа ее не трогаем, пока она занимается апдейтом таблиц:
Запрос для затравки: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=migrate+from+5.0+to+5.1+/var/lib/mysql
http://forums.mysql.com/read.php?10,323658,352152#msg-352152
Для начала просто положим папку /var/lib/mysql от 5.0 в соответствующую папку от 5.1. Далее прежде чем запустить СУБД обратим внимание на то, что в Debian есть такой прекрасный скрипт как /etc/mysql/debian-start, который делает ряд нужных нам задач: upgrade_system_tables_if_necessary (апгрейд таблиц, нам как раз и нужна эта фича, она запускает скрипт /usr/bin/mysql_upgrade, которая, во-первых, обновляет структуру самих таблиц, а, во-вторых, вносит изменения в системные таблицы), check_root_accounts, check_for_crashed_tables (проверка всех MyISAM таблиц на консистентость). Но для работы этому скрипту нужны доступы к mysql с root привилегиями, которые обеспечиваются файлом /etc/mysql/debian.cnf, который необходимо перенести со старой машины (либо просто руками скопировать root пароль).
После этой подготовки запускаем СУБД и около получаса-часа ее не трогаем, пока она занимается апдейтом таблиц:
/etc/init.d/mysql start
Запрос для затравки: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=migrate+from+5.0+to+5.1+/var/lib/mysql
http://forums.mysql.com/read.php?10,323658,352152#msg-352152
RHEL 6 beta 2, где скачать?
Что это такое и зачем: http://www.redhat.com/rhel/beta/
Вот тут: http://mirrors.kernel.org/redhat/redhat/rhel/beta/6Server-beta2/x86_64/iso/RHEL6.0-20100715.2-Server-x86_64-DVD1.iso
Вот на всякий случай чуточку более старая версия: http://mirrors.kernel.org/redhat/redhat/rhel/beta/6Server-beta2/x86_64/iso/RHEL6.0-20100622.1-Server-x86_64-DVD1.iso
Или вот тоже самое с серверов RedHat: ftp://ftp.redhat.com/pub/redhat/rhel/beta/6Server-beta2/x86_64/iso/
Вот тут: http://mirrors.kernel.org/redhat/redhat/rhel/beta/6Server-beta2/x86_64/iso/RHEL6.0-20100715.2-Server-x86_64-DVD1.iso
Вот на всякий случай чуточку более старая версия: http://mirrors.kernel.org/redhat/redhat/rhel/beta/6Server-beta2/x86_64/iso/RHEL6.0-20100622.1-Server-x86_64-DVD1.iso
Или вот тоже самое с серверов RedHat: ftp://ftp.redhat.com/pub/redhat/rhel/beta/6Server-beta2/x86_64/iso/
Thursday, 28 October 2010
Percona Server: InnoDB: The InnoDB memory heap is disabled
Такая вот штука в логе. В ней нет ничего страшного, вот пруфлинк: http://groups.google.com/group/percona-discussion/browse_thread/thread/611a0ce20e0d8c03?pli=1
Установка Percona Server 5.1 в Debian 5 Lenny
Что это и зачем: http://www.percona.com/software/percona-server/
В двух словах - это оптимизированная сборка MySQL полностью совместимая с форматами хранения "ванильного" (взятого с офсайта) MySQL (http://www.percona.com/docs/wiki/percona-xtradb:info:faq).
Обращаю внимание, что до установки стандартный MySQL должен быть удален целиком.
Импортируем ключи:
Добавляем репозиторий для APT:
Загружаем содержимое вновь подключенного репозитория:
Теперь у нас появляется целый набор ПО, который имеет в имени percona:
Для начала ставим генератор паролей:
apt-get install -y pwgen
И сгенерируем устойчивый пароль для MySQL:
Мне необходима версия сервера 5.1, поэтому я ставлю его следующими командами:
Все сопутствующие пакеты (в частности клиент) будут стянуты автоматически.
Далее рекомендую сделать mysql_secure_installation, подробнее тут: http://phpsuxx.blogspot.com/2009/12/mysql-debian5-lenny.html
Убеждаемся, что все встало корректно:
Источник: http://www.percona.com/docs/wiki/percona-server:release:start
В двух словах - это оптимизированная сборка MySQL полностью совместимая с форматами хранения "ванильного" (взятого с офсайта) MySQL (http://www.percona.com/docs/wiki/percona-xtradb:info:faq).
Обращаю внимание, что до установки стандартный MySQL должен быть удален целиком.
Импортируем ключи:
gpg --keyserver hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
gpg -a --export CD2EFD2A | apt-key add -
Добавляем репозиторий для APT:
echo "deb http://repo.percona.com/apt lenny main" >> /etc/apt/sources.list
echo "deb-src http://repo.percona.com/apt lenny main" >> /etc/apt/sources.list
Загружаем содержимое вновь подключенного репозитория:
apt-get update
Теперь у нас появляется целый набор ПО, который имеет в имени percona:
apt-cache search percona
libmysqlclient-dev - Percona Server database development files
libmysqlclient15-dev - Percona Server database development files - empty transitional package
libmysqlclient16 - Percona Server database client library
percona-server-client - Percona Server database client (metapackage depending on the latest version)
percona-server-client-5.1 - Percona Server database client binaries
percona-server-common - Percona Server database common files (e.g. /etc/mysql/my.cnf)
percona-server-server - Percona Server database server (metapackage depending on the latest version)
percona-server-server-5.1 - Percona Server database server binaries
percona-sql-client - MySQL database client (metapackage depending on the latest version)
percona-sql-client-5.0 - MySQL database client binaries
percona-sql-common - MySQL database common files
percona-sql-server - MySQL database server (metapackage depending on the latest version)
percona-sql-server-5.0 - MySQL database server binaries
Для начала ставим генератор паролей:
apt-get install -y pwgen
И сгенерируем устойчивый пароль для MySQL:
pwgen 16 1
Мне необходима версия сервера 5.1, поэтому я ставлю его следующими командами:
apt-get install -y percona-server-server-5.1
Все сопутствующие пакеты (в частности клиент) будут стянуты автоматически.
Далее рекомендую сделать mysql_secure_installation, подробнее тут: http://phpsuxx.blogspot.com/2009/12/mysql-debian5-lenny.html
Убеждаемся, что все встало корректно:
dpkg -l | grep perco
ii percona-server-client-5.1 5.1.50-11.4-111.lenny Percona Server database client binaries
ii percona-server-common 5.1.50-11.4-111.lenny Percona Server database common files (e.g. /etc/mysql/my.cnf)
ii percona-server-server-5.1 5.1.50-11.4-111.lenny Percona Server database server binaries
Источник: http://www.percona.com/docs/wiki/percona-server:release:start
Как создать на жестком диске один первичный раздел из скрипта?
parted /dev/sdb mklabel msdos
parted /dev/sdb mkpart primary ext3 0 100%
Послое этого форматируем раздел и он готов к использованию:
mkfs.ext3 /dev/sdb1
Wednesday, 27 October 2010
Google educated
Крайне рекомендовано к прочтению всем, кто имеет системных администраторов в штате, да и самим администраторам: http://semonix.ru/resources/blog/254-google-byet-spina
Tuesday, 26 October 2010
Перенос MySQL баз данных на отдельные жесткий диск в CentOS
Пусть нужно перенести MySQL на новый SSD диск /dev/sdc.
Ставим parted (CentOS):
Ставим parted (Debian):
Создаем 1 раздел на новом диске:
Форматируем его:
Гасим MySQL (CentOS):
Гасим MySQL (Debian):
Убеждаемся, что MySQL отключился:
Монтируем новый диск:
Отмонтируем новый диск:
Переносим MySQL с основного диска в бэкап папку:
Создаем папку для постоянного монтирования нового жесткого диска:
Добавляем в fstab следующее:
Монтируем:
Убеждаемся, что монтирование произведено корректно:
Далее меняем права на уже смонтированный диск:
Запускаем MySQL (CentOS):
Запускаем MySQL (Debian):
Все, теперь MySQL работает с нового жесткого диска :)
Ставим parted (CentOS):
yum install -y parted
Ставим parted (Debian):
apt-get install -y parted
Создаем 1 раздел на новом диске:
parted /dev/sdc mklabel msdos
parted /dev/sdc mkpart primary ext3 0 100%
Форматируем его:
mkfs.ext3 /dev/sdc1
Гасим MySQL (CentOS):
/etc/init.d/mysqld stop
Гасим MySQL (Debian):
/etc/init.d/mysql stop
Убеждаемся, что MySQL отключился:
ps aux | grep mysql -i
Монтируем новый диск:
mount /dev/sdc1 /mntКопируем все файлы базы на него:
cp -aR /var/lib/mysql/* /mnt
Отмонтируем новый диск:
umount /mnt
Переносим MySQL с основного диска в бэкап папку:
mv /var/lib/mysql /var/lib/mysql_old
Создаем папку для постоянного монтирования нового жесткого диска:
mkdir /var/lib/mysql
Добавляем в fstab следующее:
/dev/sdc1 /var/lib/mysql ext3 defaults 0 0
Монтируем:
mount -a
Убеждаемся, что монтирование произведено корректно:
mount | grep sdc
/dev/sdc1 on /var/lib/mysql type ext3 (rw)
Далее меняем права на уже смонтированный диск:
chown mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
Запускаем MySQL (CentOS):
/etc/init.d/mysqld start
Запускаем MySQL (Debian):
/etc/init.d/mysql start
Все, теперь MySQL работает с нового жесткого диска :)
Monday, 25 October 2010
SSD накопитель Corsair Force Series F120
Поступила в распоряжение вот такая вот железка: Corsair Force Series F120. Одной из ключевых его фич является поддержка нового контроллера: SandForce SF-1200 SSD Processor.
Вот хорошие обзоры:
http://www.storagereview.com/corsair_force_f120_ssd_review
Вот хорошие обзоры:
http://www.storagereview.com/corsair_force_f120_ssd_review
Friday, 22 October 2010
Программный архитектор - лучшая профессия в Америке!
http://money.cnn.com/magazines/moneymag/bestjobs/2010/full_list/index.html
Под "лучшая" имеется в виду "высокооплачиваемая и с большими перспективами роста".
Под "лучшая" имеется в виду "высокооплачиваемая и с большими перспективами роста".
Thursday, 21 October 2010
Что такое Tun/TAP
http://en.wikipedia.org/wiki/TUN/TAP
TAP - виртуальное L2 (Ethernet) устройство.
TUN - виртуальное L3 (IP) устройство.
Виртуальное тут в значении, что мы можем свою программу заставить заменять реальную физическую сетевую карту. Вот так-то.
TAP - виртуальное L2 (Ethernet) устройство.
TUN - виртуальное L3 (IP) устройство.
Виртуальное тут в значении, что мы можем свою программу заставить заменять реальную физическую сетевую карту. Вот так-то.
FriendlyARM - модули на ARM с поддержкой Linux
Оффффигененнные штуки: http://www.friendlyarm.net/products !!!
А еще к ниму даже есть wifi модуль: http://www.friendlyarm.net/products/accessories
А еще к ниму даже есть wifi модуль: http://www.friendlyarm.net/products/accessories
debuild - как собрать лишь один пакет, если в source пакете их несколько?
Есть такие source пакеты, например, PHP, где число пакетов достигает десятков, а пересобрать требуется лишь один. Как это сделать, подскажите?
Как отключить тесты при сборке пакета через debuild?
Вот так:
Требуется, например, при сборке MySQL, который ну очень долго тестится.
Источник: http://www.ducea.com/2008/12/07/deb_build_optionsnocheck/
DEB_BUILD_OPTIONS=nocheck debuild -us -uc
Требуется, например, при сборке MySQL, который ну очень долго тестится.
Источник: http://www.ducea.com/2008/12/07/deb_build_optionsnocheck/
Wednesday, 20 October 2010
Как узнать, сколько оперативной памяти свободно на моем сервере? Команда free
Наверное, уже раз 100 объяснил, как считать "правильный" (за вычетом cached) объем свободной оперативной памяти в top и по глупости не догадывался, что команда free как раз это и делает - http://markelov.blogspot.com/2009/01/binfree.html :)))
Руководство по повышению безопасности RHEL5 (CentOS 5) от АНБ (NSA) США
Ссылка: http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf (внимание, 170 страниц!)
А вот краткий набор советов по безопасности: http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf (рекомендую ВСЕМ! Хотя, на мой взгляд, не все там однозначно)
Зеркала ссылок искать здесь: http://code.google.com/p/fastvps/source/browse/#svn/trunk/other
А вот краткий набор советов по безопасности: http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf (рекомендую ВСЕМ! Хотя, на мой взгляд, не все там однозначно)
Зеркала ссылок искать здесь: http://code.google.com/p/fastvps/source/browse/#svn/trunk/other
Протестируйте свои знания Linux: LPI и RedHat сертификации
Сравнение сильных и слабых сторон каждого из них: http://markelov.blogspot.com/2007/02/lpi-linux-format-pdf.html
О Windows 2008
Как ни странно, но серверная ОС, которую можно почти комфортно эксплуатировать, у Microsoft-таки получилась, [s]с 2008 попытки[/s] в 2008 версии.
Вчера буквально столкнулись с нестандартным поведением программного зеркала в Windows 2008 - все типично до боли, отказал жесткий диск из программного зеркала (до такой степени, что даже Линукс LiveCD его в упор не видел), заменили, загружаем Windows - она нам BSOD (да, кстати, теперь они читаемы, а не сплошные кракозяблы!), идем с ошибкой в Гугл - совпадений нету, ну что же, приехали.
В обычных условиях я бы без угрызений совести снял данные с диска и переустановил ОС, но не тут-то было - Windows предложил нам (сам!) ряд утилит по восстановлению системы, среди которых тест памяти и консоль! После недолгих колебаний, наш администратор Николай (кстати, для всех связанных с хостингом рекомендую его блог) вошел в эту консольку и быстренько добрался до diskpart, а далее победа над проблемой уже была делом техники (кстати, то, что было в итоге сделано похоже на FreeBSD`шное gmirror forget gm0). В итоге после перезагрузки система загрузилась на одном диске и через пару минут уже весело синхронизировала раздел свое зеркало :)
В процессе гугления заметил еще одну фичу - все мануалы по серверным ОС Windows снабжены двумя версиями инструкций - одна для граф оболочки, другая для (не поверите!) консоли. Что же, даже RedHat частеньно выпускает "графика онли" инструкции, а Microsof`у зачет :)
Вчера буквально столкнулись с нестандартным поведением программного зеркала в Windows 2008 - все типично до боли, отказал жесткий диск из программного зеркала (до такой степени, что даже Линукс LiveCD его в упор не видел), заменили, загружаем Windows - она нам BSOD (да, кстати, теперь они читаемы, а не сплошные кракозяблы!), идем с ошибкой в Гугл - совпадений нету, ну что же, приехали.
В обычных условиях я бы без угрызений совести снял данные с диска и переустановил ОС, но не тут-то было - Windows предложил нам (сам!) ряд утилит по восстановлению системы, среди которых тест памяти и консоль! После недолгих колебаний, наш администратор Николай (кстати, для всех связанных с хостингом рекомендую его блог) вошел в эту консольку и быстренько добрался до diskpart, а далее победа над проблемой уже была делом техники (кстати, то, что было в итоге сделано похоже на FreeBSD`шное gmirror forget gm0). В итоге после перезагрузки система загрузилась на одном диске и через пару минут уже весело синхронизировала раздел свое зеркало :)
В процессе гугления заметил еще одну фичу - все мануалы по серверным ОС Windows снабжены двумя версиями инструкций - одна для граф оболочки, другая для (не поверите!) консоли. Что же, даже RedHat частеньно выпускает "графика онли" инструкции, а Microsof`у зачет :)
Альтернативный интерпретатор Ruby - Rubinius
Как выгрузить всю Linux систему (/) в систему контроля версий?
Сабж. Какую VCS (систему контроля версий) использовать, чтобы вгрузить в нее мегабайт 200-400? Тип контента - иерархия папок Линукс системы, полная. Разумеется, также нужно, чтобы в каждой папке не было подпапки .svn, ибо подпапок тыщи и вычищать будет сложно.
Итого, требование можно сформулировать как:
Как вариант Гугл сразу подсказывает:
Bazaar
Вот Bazaar сами разработчики не рекомендуют:
Также Bazaar не умеет трекить пермишшены и овнеров:
Источник: http://wiki.bazaar.canonical.com/FAQ#Are binary files handled?
Subversion
Subversion также не подходит, так как заспамливает все папки своими .svn.
Mercurial
Далее Mercurial имеет вполне крупные примеры используемых репо: http://mercurial.selenic.com/wiki/RepoSamples
Но имеет неприятную фичу, он не умеет хранить пустые папки: пруфлинк
Общее
Вот список VCS, которые умеют хранить просто пустые папки: http://stackoverflow.com/questions/1080174/scm-vcs-tracking-directories
Заключение
Похоже, то, что я хочу реализовать не получится через VCS ну никак. Разве что подключать Puppet и делать все изменения через него, тогда ничего не потеряется точно :) И он как раз ругается (точнее показывает диффы конфигов), как только замечает, какие файлы изменились.
Итого, требование можно сформулировать как:
VCS with permissions, owners and blank folders tracking
Как вариант Гугл сразу подсказывает:
etckeeper - store /etc in git, mercurial, or bzr
Bazaar
Вот Bazaar сами разработчики не рекомендуют:
That said, bzr is primarily a source code control system, not a media archive system. So it is not a priority to support enormous (hundred-megabyte) binaries or multi-gigabyte trees. There are other tools better suited to that.
Также Bazaar не умеет трекить пермишшены и овнеров:
Versions of Bazaar of 0.1 and later support the tracking of the executable bit. Other permission bits are not currently tracked.
Источник: http://wiki.bazaar.canonical.com/FAQ#Are binary files handled?
Subversion
Subversion также не подходит, так как заспамливает все папки своими .svn.
Mercurial
Далее Mercurial имеет вполне крупные примеры используемых репо: http://mercurial.selenic.com/wiki/RepoSamples
Но имеет неприятную фичу, он не умеет хранить пустые папки: пруфлинк
Общее
Вот список VCS, которые умеют хранить просто пустые папки: http://stackoverflow.com/questions/1080174/scm-vcs-tracking-directories
Заключение
Похоже, то, что я хочу реализовать не получится через VCS ну никак. Разве что подключать Puppet и делать все изменения через него, тогда ничего не потеряется точно :) И он как раз ругается (точнее показывает диффы конфигов), как только замечает, какие файлы изменились.
Tuesday, 19 October 2010
Саркози прогнозирует отмену виз между Россией и ЕС через 10-15 лет
Хаха, оптимистично :)
Установка и использование qemu на Debian OpenVZ VPS
Итак, у нас есть 64 битный VPS на OpenVZ, а мы хотим на нем водрузить еще одну ОС, возможно ли это? :) Вполне!
Устанавливаем qemu:
Создаем папку для тестов:
Скачиваем образ Debian Net Install (32 битный дан ради примера гибкости qemu, 64 битный будет также замечательно работать):
Создаем образ диска виртуальной машины:
Запускаем (Аккуратно! у меня лимит памяти для qemu стоит в 128 мегабайт!):
"-boot d" означает загрузку с CD-ROM, а "-boot c" с образа жесткого диска.
После этого нам понадобится программа VNC viewer (это нечто в стиле протокола RDP, только для Linux), чтобы увидеть радостный экран начала установки Debian. Обращаю внимание, что VNC соединение никак не защищается и доступно всем подряд, так что надолго его оставлять не рекомендую, также хотелось бы заметить, что в настройках программы нужно выбирать Display 1.
Но фишка в том, что данный вариант у меня не заработал и пришлось скачать готовые qemu образы со стороннего сайта: http://blog.aurel32.net/?p=46 и попробовать их запустить, при этом все заработало на ура (проверял 32 и 64 битные образы Debian Lenny, все работает на ура!). Так что могу констатировать факт, что все работает отлично, за исключением (по каким-то причинам) загрузки с CD.
Вот, что именно я сделал (скачиваем 32 и 64 битные образы для qemu):
И запускаем 32 битный Debian:
Или 64 битный:
При эмуляции 64 битных систем будет выдаваться ошибка "Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory", но ее можно смело игнорировать.
Заключение: запуск qemu на OpenVZ возможен, но сопряжен с некоторыми проблемами, во-первых, не стоит пытаться включить поддержку kqemu (OpenVZ не поддерживает загрузку модулей ядра), во-вторых, не стоит забывать, что у VPE нету монитора и в качествен него нужно использовать VNC (или подобные технологии), а также стоит быть аккуратнее с настройками сети, не увлекаться с виртуальными бриджами и прочим - OpenVZ это также сделать не позволит.
По большей части основано на: http://phpsuxx.blogspot.com/2009/08/freebsd-72-qemu.html
Устанавливаем qemu:
apt-get install -y qemu
Создаем папку для тестов:
mkdir /opt/debian
cd /opt/debian
Скачиваем образ Debian Net Install (32 битный дан ради примера гибкости qemu, 64 битный будет также замечательно работать):
wget http://cdimage.debian.org/debian-cd/5.0.6/i386/iso-cd/debian-506-i386-netinst.iso
Создаем образ диска виртуальной машины:
qemu-img create -f raw /opt/debian/debian5.img 2G
Запускаем (Аккуратно! у меня лимит памяти для qemu стоит в 128 мегабайт!):
qemu -hda /opt/debian/debian5.img -cdrom /opt/debian/debian-506-i386-netinst.iso -boot d -m 128 -vnc :1
"-boot d" означает загрузку с CD-ROM, а "-boot c" с образа жесткого диска.
После этого нам понадобится программа VNC viewer (это нечто в стиле протокола RDP, только для Linux), чтобы увидеть радостный экран начала установки Debian. Обращаю внимание, что VNC соединение никак не защищается и доступно всем подряд, так что надолго его оставлять не рекомендую, также хотелось бы заметить, что в настройках программы нужно выбирать Display 1.
Но фишка в том, что данный вариант у меня не заработал и пришлось скачать готовые qemu образы со стороннего сайта: http://blog.aurel32.net/?p=46 и попробовать их запустить, при этом все заработало на ура (проверял 32 и 64 битные образы Debian Lenny, все работает на ура!). Так что могу констатировать факт, что все работает отлично, за исключением (по каким-то причинам) загрузки с CD.
Вот, что именно я сделал (скачиваем 32 и 64 битные образы для qemu):
cd /opt/debian
wget http://people.debian.org/~aurel32/qemu/i386/debian_etch_i386_small.qcow2
wget http://people.debian.org/~aurel32/qemu/amd64/debian_etch_amd64_small.qcow2
И запускаем 32 битный Debian:
qemu -hda debian_etch_i386_small.qcow2 -boot c -m 128 -vnc :1
Или 64 битный:
qemu-system-x86_64 -hda debian_etch_amd64_small.qcow2 -boot c -m 128 -vnc :1
При эмуляции 64 битных систем будет выдаваться ошибка "Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory", но ее можно смело игнорировать.
Заключение: запуск qemu на OpenVZ возможен, но сопряжен с некоторыми проблемами, во-первых, не стоит пытаться включить поддержку kqemu (OpenVZ не поддерживает загрузку модулей ядра), во-вторых, не стоит забывать, что у VPE нету монитора и в качествен него нужно использовать VNC (или подобные технологии), а также стоит быть аккуратнее с настройками сети, не увлекаться с виртуальными бриджами и прочим - OpenVZ это также сделать не позволит.
По большей части основано на: http://phpsuxx.blogspot.com/2009/08/freebsd-72-qemu.html
MySQL, php-mysql и localhost
Считаете, что localhost - означает подключение к 127.0.0.1? Как бы не так! В MySQL / php-mysql это означает, что мы к MySQL серверу коннектимся по UNIX сокету, а не по сети! Хотите по сети - пишите 127.0.0.1. Вот такая вот неприятная и неожиданная фича.
У библиотеки mysqli-php формулировка немного иная:
То есть, тут "предпочтительно", а как влиять на эту предпочтительность также непонятно :)
Источники:
http://php.net/manual/en/function.mysql-connect.php
http://www.php.net/manual/en/mysqli.connect.php
Whenever you specify "localhost" or "localhost:port" as server, the MySQL client library will override this and try to connect to a local socket (named pipe on Windows). If you want to use TCP/IP, use "127.0.0.1" instead of "localhost". If the MySQL client library tries to connect to the wrong local socket, you should set the correct path as in your PHP configuration and leave the server field blank.
У библиотеки mysqli-php формулировка немного иная:
Can be either a host name or an IP address. Passing the NULL value or the string "localhost" to this parameter, the local host is assumed. When possible, pipes will be used instead of the TCP/IP protocol.
Prepending host by p: opens a persistent connection. mysqli_change_user() is automatically called on connections opened from the connection pool.
То есть, тут "предпочтительно", а как влиять на эту предпочтительность также непонятно :)
Источники:
http://php.net/manual/en/function.mysql-connect.php
http://www.php.net/manual/en/mysqli.connect.php
Проксирование MySQL запросов
Для реализации задачи есть как минимум пара проектов:
1. http://sqlrelay.sourceforge.net/
2. http://forge.mysql.com/wiki/MySQL_Proxy
1. http://sqlrelay.sourceforge.net/
2. http://forge.mysql.com/wiki/MySQL_Proxy
Интересные железки :)
Любому технику в подарок: http://amperka.ru/
vBulletin - ссылка на последнюю страницу темы
Достаточно ввести несуществующий и заведомо больший, чем число страниц в теме, номер страницы, например:
Тогда ссылка будет всегда вести на последнюю страницу темы.
page=100
Тогда ссылка будет всегда вести на последнюю страницу темы.
Как узнать UUID раздела в Linux?
blkid /dev/sda1
В ответ Вы увидите ряд полей, среди которых будет и нужный нам UUID:
blkid /dev/sda1
/dev/sda1: TYPE="swap" UUID="2af30e5c-a2bf-4f7a-a46f-b16db7fc3771"
Также соответствие "классических" имен устройств и их UUID представлений можно посмотреть вот так:
ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Oct 8 14:32 2af30e5c-a2bf-4f7a-a46f-b16db7fc3771 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 8 14:32 6589b269-c1de-42bc-b767-697f9a91e49a -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 8 14:32 addfa536-4bfb-4693-9182-a464a565fb45 -> ../../sda2
Источник: http://linux.byexamples.com/archives/321/fstab-with-uuid/
Monday, 18 October 2010
Проброс портов посредством SSH
Итак, допустим, у нас есть удаленный сервер, доступ к которому возможен лишь по ssh. А нам непременно нужно достучаться до MySQL сервера, установленного на той же машине (или внутри сети, в которой имеет доступ только удаленная машина), то что делать? Очень просто - сделать ssh туннель.
Сделать его проще простого, на клиентской машине делаем следующее:
Где -L 3306:127.0.0.1:3306 - это порт на локальной машине, к которому будет подключен удаленный сервис; адрес удаленного сервера (либо это может быть 127.0.0.1 в случае подключения к локальному сервису машины, к которой у нас имеется ssh доступ), к которому нужно подключиться и порт на нем; -f означает переход в фоновый режим сразу после выполнения заданной команды; -N отключает требование выполнять какую-либо команду на удаленной машине; ssh-server.ru - машина, к которой мы имеем доступ по ssh, а login - логин на этой машине.
После выполнения команды она запросит пароль, его нужно ввести (либо настроить вход на сертификатах).
Далее убеждаемся, что ssh слушает необходимый нам порт:
Все, теперь пробуем подключиться к MySQL:
В реальности же мы подключились к удаленной машине!
Теперь можно поставить MySQL клиент и проверить его работу:
И, вуаля:
Остановка туннеля:
А как сделать тоже самое без ssh и шифрования? Вот этим софтом:
Сделать его проще простого, на клиентской машине делаем следующее:
ssh -L 3306:remote-server.ru:3306 -f -N login@ssh-server.ru sleep 10
Где -L 3306:127.0.0.1:3306 - это порт на локальной машине, к которому будет подключен удаленный сервис; адрес удаленного сервера (либо это может быть 127.0.0.1 в случае подключения к локальному сервису машины, к которой у нас имеется ssh доступ), к которому нужно подключиться и порт на нем; -f означает переход в фоновый режим сразу после выполнения заданной команды; -N отключает требование выполнять какую-либо команду на удаленной машине; ssh-server.ru - машина, к которой мы имеем доступ по ssh, а login - логин на этой машине.
После выполнения команды она запросит пароль, его нужно ввести (либо настроить вход на сертификатах).
Далее убеждаемся, что ssh слушает необходимый нам порт:
netstat -lnpt | grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 4578/ssh
tcp6 0 0 ::1:3306 :::* LISTEN 4578/ssh
Все, теперь пробуем подключиться к MySQL:
telnet 127.0.0.1 3306
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
?
5.0.51a-24+lenny4J)+;)[n8,j/KhL#hd;;Tt
В реальности же мы подключились к удаленной машине!
Теперь можно поставить MySQL клиент и проверить его работу:
apt-get install mysql-client -y
И, вуаля:
mysql --host=127.0.0.1 -uroot -p -e 'show databases;'
Enter password:
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
+--------------------+
Остановка туннеля:
ps aux | grep 'ssh -L'
kill пид_нашего_процесса
А как сделать тоже самое без ssh и шифрования? Вот этим софтом:
rinetd - Internet TCP redirection server
socat - multipurpose relay for bidirectional data transfer
Редирект с localhost:3306 на удаленный сервер MySQL средствами iptables
Задача: требуется все коннекты на localhost (127.0.0.1:3306) отправлять на удаленный сервер и корректно возвращать его ответ запросившему клиенту.
Переброс MySQL с одного порта на другой, в пределах одной машины
Итак, для начала попробуем сделать локальный проброс, то есть, чтобы при подключении к порту 33060 нам в реальности откликался 3306 порт, по которому работает MySQL.
Для тестов нам понадобится telnet:
Итак, убедимся, что MySQL работает на 3306 порту:
Попробуем подключиться к MySQL посредством telnet:
Теперь подключим к фаерволлу вот такое правило, которое перебросит все запросы с 33060 порта на 3306 посредством цели REDIRECT (которая делает примерно следующее - "It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface"):
Теперь проверим телнетом:
Визуально, все работает, но будет ли работать mysql клиент?
Еще как будет, смотрим:
Переброс запросов к локалхосту на 3306 порт на удаленный сервер
Итак, теперь нам для тестов нужна еще одна машина с mysql клиентов и telnet:
На первой же машине (с MySQL) нужно открыть MySQL наружу, чтобы он слушал внешний интерфейс:
И в блоке mysqld сделать следующую правку:
И перезаупстить сервер:
Теперь на второй машине-клиенте забрасываем весь трафик выходящий с интерфейса localhost на внешний сервер:
После часов извращений (убрав -o lo и подключаясь не к локалхосту, а к внешнему IP клиент машину) я добился того, что:
Но команда, которая может завернуть обращения к localhost наружу по-прежнему упорно не работает:
У кого есть идеи? Все машины Debian Lenny 5, а также тестил на 2.6.33.
Update:
Работать это не будет принципиально, вот такой вот iptables!
По материалам:
1. http://forums.cpanel.net/f5/iptables-redirect-internal-port-remote-mysql-98333.html (рекомендуют NAT)
2. http://ubuntuforums.org/showthread.php?t=1436579 (попытки применить NAT)
3. http://www.linuxquestions.org/questions/showthread.php?p=3909624#post3909624 (еще немного по iptables)
4. http://forum.slicehost.com/comments.php?DiscussionID=4647 (готовое решение!)
5. http://wiki.debian.org/Firewalls-local-port-redirection (примеры порт редиректа! готовые!)
6. http://www.linuxquestions.org/questions/linux-networking-3/iptables-how-to-redirect-locally-generated-packets-to-a-remote-server-797173/
7. http://www.experts-exchange.com/Networking/Linux_Networking/Q_22862486.html (проблема DNAT + loopback)
8. http://lists.netfilter.org/pipermail/netfilter/2005-April/059765.html (пару слов про необходимость CONFIG_IP_NF_NAT_LOCAL)
9. Ссылка на "как это сделать через iproute2": http://www.listware.net/201007/debian-user/27927-iptables-localhost-redirect.html
Переброс MySQL с одного порта на другой, в пределах одной машины
Итак, для начала попробуем сделать локальный проброс, то есть, чтобы при подключении к порту 33060 нам в реальности откликался 3306 порт, по которому работает MySQL.
Для тестов нам понадобится telnet:
apt-get install -y telnet
Итак, убедимся, что MySQL работает на 3306 порту:
netstat -lnpt | grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 4667/mysqld
Попробуем подключиться к MySQL посредством telnet:
telnet 127.0.0.1 3306
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
?
5.0.51a-24+lenny4,X!6,zD$',5se"tHHp|?bSC
Теперь подключим к фаерволлу вот такое правило, которое перебросит все запросы с 33060 порта на 3306 посредством цели REDIRECT (которая делает примерно следующее - "It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface"):
iptables -t nat -I OUTPUT --src 0/0 --dst 127.0.0.1 -p tcp --dport 33060 -j REDIRECT --to-ports 3306
Теперь проверим телнетом:
telnet 127.0.0.1 33060Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
?
5.0.51a-24+lenny4-KDSV4@(C,WoGTPv"@\/sv
Визуально, все работает, но будет ли работать mysql клиент?
Еще как будет, смотрим:
mysql --host=127.0.0.1 -uroot -pyour_password --port 33060 -e 'show databases;;'
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
+--------------------+
Переброс запросов к локалхосту на 3306 порт на удаленный сервер
Итак, теперь нам для тестов нужна еще одна машина с mysql клиентов и telnet:
apt-get install -y telnet
На первой же машине (с MySQL) нужно открыть MySQL наружу, чтобы он слушал внешний интерфейс:
vi /etc/mysql/my.cnf
И в блоке mysqld сделать следующую правку:
bind-address = 0.0.0.0
И перезаупстить сервер:
/etc/init.d/mysql restart
Теперь на второй машине-клиенте забрасываем весь трафик выходящий с интерфейса localhost на внешний сервер:
iptables -t nat -A OUTPUT -p tcp --dport 3306 -j DNAT --to ext.ernal.ip.addr:3306
После часов извращений (убрав -o lo и подключаясь не к локалхосту, а к внешнему IP клиент машину) я добился того, что:
telnet ext.ernal.ip.addr
Trying ext.ernal.ip.addr...
Connected to ext.ernal.ip.addr.
Escape character is '^]'.
dHost 'xxxx' is not allowed to connect to this MySQL serverConnection closed by foreign host.
Но команда, которая может завернуть обращения к localhost наружу по-прежнему упорно не работает:
iptables -t nat -A OUTPUT -p tcp -o lo --dport 3306 -j DNAT --to ip_of_server_with_mysql:3306
У кого есть идеи? Все машины Debian Lenny 5, а также тестил на 2.6.33.
Update:
Работать это не будет принципиально, вот такой вот iptables!
По материалам:
1. http://forums.cpanel.net/f5/iptables-redirect-internal-port-remote-mysql-98333.html (рекомендуют NAT)
2. http://ubuntuforums.org/showthread.php?t=1436579 (попытки применить NAT)
3. http://www.linuxquestions.org/questions/showthread.php?p=3909624#post3909624 (еще немного по iptables)
4. http://forum.slicehost.com/comments.php?DiscussionID=4647 (готовое решение!)
5. http://wiki.debian.org/Firewalls-local-port-redirection (примеры порт редиректа! готовые!)
6. http://www.linuxquestions.org/questions/linux-networking-3/iptables-how-to-redirect-locally-generated-packets-to-a-remote-server-797173/
7. http://www.experts-exchange.com/Networking/Linux_Networking/Q_22862486.html (проблема DNAT + loopback)
8. http://lists.netfilter.org/pipermail/netfilter/2005-April/059765.html (пару слов про необходимость CONFIG_IP_NF_NAT_LOCAL)
9. Ссылка на "как это сделать через iproute2": http://www.listware.net/201007/debian-user/27927-iptables-localhost-redirect.html
Тестирование пропускной способности сети между узлами посредством iperf
Устанавливаем на обоих серверах:
Запускаем сервер на первой машине :
На клиенте делаем следующее:
Как результат на клиенте будет выдано примерно следующее на сервере:
Процесс выглядит следующим образом - клиент шлет исходящий tcp поток в сторону сервера. Сервер лишь принимает его и все.
Чтобы погонять тест несколько суток добавляем клиенту ключики -t и -i (-i интервал между отчетами):
Источник: http://www.ttk.ru/www/nsf/site.nsf/all/32DC8C9E2B6541A8C325705A0049A03B
apt-get install -y iperf screen
Запускаем сервер на первой машине :
screen
iperf --server --port 5001
На клиенте делаем следующее:
screen
iperf --client ip.ad.dr.es --port 5001
Как результат на клиенте будет выдано примерно следующее на сервере:
------------------------------------------------------------
Client connecting to xx.xx.xx.xx, TCP port 5001
TCP window size: 1.00 MByte (default)
------------------------------------------------------------
[ 3] local xx.xx.xx.xx port 58091 connected with xx.xx.xx.xx port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 113 MBytes 94.9 Mbits/sec
[ 3] 0.0-10.0 sec 113 MBytes 94.7 Mbits/sec
Процесс выглядит следующим образом - клиент шлет исходящий tcp поток в сторону сервера. Сервер лишь принимает его и все.
Чтобы погонять тест несколько суток добавляем клиенту ключики -t и -i (-i интервал между отчетами):
-t 86400 -i 60
Источник: http://www.ttk.ru/www/nsf/site.nsf/all/32DC8C9E2B6541A8C325705A0049A03B
Веб-интерфейсы для PowerDNS
Poweradmin: http://poweradmin.org
MoxieDNS: http://moxiefoxtrot.com/2009/01/07/powerdns-web-frontend/
JPower Admin: http://www.nicmus.com/community.html
Powerdns on Rails: http://kennethkalmer.github.com/powerdns-on-rails/
MoxieDNS: http://moxiefoxtrot.com/2009/01/07/powerdns-web-frontend/
JPower Admin: http://www.nicmus.com/community.html
Powerdns on Rails: http://kennethkalmer.github.com/powerdns-on-rails/
Как сделать литинг папки без ls, dir, find и прочих?
echo *
Вот была такая необходимость :)
Sunday, 17 October 2010
Удобный способ бронирования авиабилетов
Рекомендую: http://www.agent.ru/ а также: http://www.ozon.travel/
Эти сайты намного удобнее, чем сайты большинства авиакомпаний (за исключением, пожалуй S7 и Аэрофлота) :)
Эти сайты намного удобнее, чем сайты большинства авиакомпаний (за исключением, пожалуй S7 и Аэрофлота) :)
Skype API
Ссылка на сабжевую документацию: http://developer.skype.com/accessories
Вариантов обмена данными со Skype в случае Linux по этому самому API как минимум несколько:
Про X-11 сказано следующее:
Так что, D-Bus предпочтительнее.
А вот пару слов про запуск Skype без граф оболочки: http://forum.skype.com/index.php?showtopic=46154
А вот про установку Skype на Debian:
А вот и реализация клиентской библиотеки на Python: http://sourceforge.net/projects/skype4py/
Вариантов обмена данными со Skype в случае Linux по этому самому API как минимум несколько:
D-BUS messaging
X11 messaging
Про X-11 сказано следующее:
Note: X11 messaging is still under development. The final release of Skype for Linux API, version 1.3, will include examples of working with X11 and a description of the Skype action handler for X11.
Так что, D-Bus предпочтительнее.
А вот пару слов про запуск Skype без граф оболочки: http://forum.skype.com/index.php?showtopic=46154
А вот про установку Skype на Debian:
http://wiki.debian.org/skype
А вот и реализация клиентской библиотеки на Python: http://sourceforge.net/projects/skype4py/
chroot: cannot run command `/bin/bash': No such file or directory
С такой проблемой столкнуться очень легко - достаточно удалить пару библиотек внутри системы или VPS. Бороться с напастью мы будем из Debian LiveCD.
Ставим спецовый баш, который не имеет зависимостей - он слинкован статически (и удаленные либы ему безразличны):
Данный пакетик несет в себе множество файлов:
Но нам нужен лишь один - /bin/bash-static.
Итак, допустим сломанная система смонтирована как /mnt. Тогда нужно сделать следующее:
Вуаяля, чрут сработал :)
Ставим спецовый баш, который не имеет зависимостей - он слинкован статически (и удаленные либы ему безразличны):
apt-get install -y bash-static
Данный пакетик несет в себе множество файлов:
dpkg -L bash-static
/.
/bin
/bin/bash-static
/usr
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/bash-static.1.gz
/usr/share/doc
/usr/share/doc/bash-static
/usr/share/doc/bash-static/copyright
/usr/share/doc/bash-static/changelog.Debian.gz
Но нам нужен лишь один - /bin/bash-static.
Итак, допустим сломанная система смонтирована как /mnt. Тогда нужно сделать следующее:
cp /bin/bash-static /mnt/bin
chroot /mnt /bin/bash-static
Вуаяля, чрут сработал :)
Saturday, 16 October 2010
sshproxy - безопасный доступ к ssh
Так как офсайт лежит, выкладываю сссылку на Debian:
http://packages.debian.org/lenny/sshproxy
http://packages.debian.org/lenny/sshproxy
Утилита для не интерактивного логина на ssh сервера
http://sourceforge.net/projects/sshpass/
Обращаю внимание, что этот вариант использования ssh крайне небезопасен!
Обращаю внимание, что этот вариант использования ssh крайне небезопасен!
Возможен ли обмен данными между двумя сетями в пределах 1 свитч без роутера
Похоже, что да (тесты првоедены на Apple Mac 10.5.8 и Windows XP SP2):
То есть, по локальной сети система начала отправлять ARP запросы, которые используются лишь при обмене данными внутри локальной сети.
Если же поднять интерфейс 1.2.3.4 с маской 255.255.255.0 на соседней машине, подключенной к этому же свитчу (в моем случае она была с Windows XP), то tcpdump покажет примерно следующее:
И пинг заработает:
А arp в свою очередь закэширует адрес второй машины:
В процессе тестов все работала стабильно, так что, полагаю, данный вариант вполне работоспособен при сопряжении двух различных сетей построенных на одном свитче.
ifconfig en0
en0: flags=8863mtu 1500
inet6 fe80::226:8ff:fe09:fbea%en0 prefixlen 64 scopeid 0x4
inet 192.168.155.111 netmask 0xffffff00 broadcast 192.168.155.255
ether 00:26:08:09:fb:ea
media: autoselect (100baseTX) status: active
supported media: none autoselect 10baseT/UTP10baseT/UTP 10baseT/UTP 10baseT/UTP 100baseTX 100baseTX 100baseTX 100baseTX 1000baseT 1000baseT 1000baseT
sudo route add 1.2.3.4 0.0.0.0
add host 1.2.3.4: gateway 0.0.0.0
ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
^C
--- 1.2.3.4 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
sudo tcpdump -i en0 "arp"
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes
20:21:51.948290 arp who-has 1.2.3.4 tell 192.168.155.111
20:21:52.580102 arp who-has 1.2.3.4 tell 192.168.155.111
^C
2 packets captured
420 packets received by filter
0 packets dropped by kernel
То есть, по локальной сети система начала отправлять ARP запросы, которые используются лишь при обмене данными внутри локальной сети.
Если же поднять интерфейс 1.2.3.4 с маской 255.255.255.0 на соседней машине, подключенной к этому же свитчу (в моем случае она была с Windows XP), то tcpdump покажет примерно следующее:
21:36:43.368393 arp reply 1.2.3.4 is-at 00:19:b9:4e:e2:91 (oui Unknown)
21:36:43.368556 arp who-has 192.168.155.1 tell 1.2.3.4
И пинг заработает:
macbook-pavel-odincov:~ nrg$ ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
64 bytes from 1.2.3.4: icmp_seq=0 ttl=127 time=0.930 ms
64 bytes from 1.2.3.4: icmp_seq=1 ttl=127 time=0.589 ms
64 bytes from 1.2.3.4: icmp_seq=2 ttl=127 time=0.675 ms
64 bytes from 1.2.3.4: icmp_seq=3 ttl=127 time=0.688 ms
64 bytes from 1.2.3.4: icmp_seq=4 ttl=127 time=0.559 ms
^C
--- 1.2.3.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.559/0.688/0.930/0.131 ms
macbook-pavel-odincov:~ nrg$ ping 192.168.155.1
PING 192.168.155.1 (192.168.155.1): 56 data bytes
64 bytes from 192.168.155.1: icmp_seq=0 ttl=255 time=0.447 ms
64 bytes from 192.168.155.1: icmp_seq=1 ttl=255 time=0.423 ms
64 bytes from 192.168.155.1: icmp_seq=2 ttl=255 time=0.444 ms
64 bytes from 192.168.155.1: icmp_seq=3 ttl=255 time=0.430 ms
^C
--- 192.168.155.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.423/0.436/0.447/0.010 ms
А arp в свою очередь закэширует адрес второй машины:
arp -a
? (1.2.3.4) at 0:19:b9:4e:e2:91 on en0 [ethernet]
? (192.168.155.1) at 0:1c:f0:a9:78:9c on en0 [ethernet]
В процессе тестов все работала стабильно, так что, полагаю, данный вариант вполне работоспособен при сопряжении двух различных сетей построенных на одном свитче.
Взлет с карьерного плато, видео
Открываю новый тег в блоге "Карьера" и сразу же всем рекомендую к просмотру видео: http://habrahabr.ru/blogs/arbeit/106238/
Friday, 15 October 2010
OpenVZ, CentOS, VDSManager и куча мусора в виде дисков VPS после переустановки ОС
После того, как клиенты много-много раз переустанавливают VPS, в папке /vz/private образуется огромное число папок вида: CTID.тут_некое_большое_целое_число, в которых сохранятся состояния дисков контейнеров до переустановки.
Удалять их автоматически можно вот таким скриптом:
Удалять их автоматически можно вот таким скриптом:
for i in `/bin/ls /vz/private/ | egrep '^[0-9]+\.[0-9]+$'`; do echo "Remove folder: $i"; rm -rf /vz/private/$i ; done
Реализация IPv4 anycast
http://en.wikipedia.org/wiki/Anycast
А вот отличный хав-ву по настройке IPv4 anycast для балансировки нагрузки, а также пару слов о борьбе с DDoS посредством anycast: http://www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.pdf.
А вот отличный хав-ву по настройке IPv4 anycast для балансировки нагрузки, а также пару слов о борьбе с DDoS посредством anycast: http://www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.pdf.
Thursday, 14 October 2010
Обалденный математический "поисковик" !
Прошу: http://www.wolframalpha.com/
Вот пример ее в работе: http://www.wolframalpha.com/input/?i=x^2%2By^2%3D5^2
Вот пример ее в работе: http://www.wolframalpha.com/input/?i=x^2%2By^2%3D5^2
Wednesday, 13 October 2010
Балансировка сервисов посредством Bind / named.
Уверен, многим известно, что доменная запись может резолвится в несколько IP адресов. Так, например, сделано у Google и Yandex:
Для чего это делается? Крайне просто - для балансировки нагрузки по множеству машин и для повышенной отказоустойчивости (если какой-то из серверов упадет, часть клиентов будет уходить на другие машины, а когда IP отказавшей машины будет изъят из DNS, то через некоторое время на отказавший сервер клиенты идти перестанут совсем).
Как же реализовать такой механизм, имея в арсенале лишь обычный DNS сервис Bind? Крайне просто - достаточно добавить две идентичных ресурсных А записи, указывающих на разные IP адреса:
И перезапустить Bind. После этого IP адреса начнут выдаваться в циклическом порядке (то есть, сначала первым в выдаче nslookup будет первый IP, потом второй, при следующем запросе они поменяются местами, потом еще раз и т.д. и т.п.). Если же Вам интересен более сложный порядок выдачи адресов, то рекомендую вот эту статью.
Выглядеть это будет так:
Ну вот и все :)
Источник: http://www.zytrax.com/books/dns/ch9/rr.html#services
nslookup google.com
Server: 192.168.155.1
Address: 192.168.155.1#53
Non-authoritative answer:
Name: google.com
Address: 74.125.232.19
Name: google.com
Address: 74.125.232.16
Name: google.com
Address: 74.125.232.17
Name: google.com
Address: 74.125.232.20
Name: google.com
Address: 74.125.232.18
nslookup ya.ru
Server: 192.168.155.1
Address: 192.168.155.1#53
Non-authoritative answer:
Name: ya.ru
Address: 213.180.204.3
Name: ya.ru
Address: 77.88.21.3
Name: ya.ru
Address: 87.250.250.3
Name: ya.ru
Address: 87.250.251.3
Name: ya.ru
Address: 93.158.134.3
Для чего это делается? Крайне просто - для балансировки нагрузки по множеству машин и для повышенной отказоустойчивости (если какой-то из серверов упадет, часть клиентов будет уходить на другие машины, а когда IP отказавшей машины будет изъят из DNS, то через некоторое время на отказавший сервер клиенты идти перестанут совсем).
Как же реализовать такой механизм, имея в арсенале лишь обычный DNS сервис Bind? Крайне просто - достаточно добавить две идентичных ресурсных А записи, указывающих на разные IP адреса:
testzone IN A 82.11.22.33
testzone IN A 77.11.22.33
И перезапустить Bind. После этого IP адреса начнут выдаваться в циклическом порядке (то есть, сначала первым в выдаче nslookup будет первый IP, потом второй, при следующем запросе они поменяются местами, потом еще раз и т.д. и т.п.). Если же Вам интересен более сложный порядок выдачи адресов, то рекомендую вот эту статью.
Выглядеть это будет так:
nslookup testzone.domain.ru ns1.domain.ru
Server: ns1.domain.ru
Address: 78.xx.xx.xx#53
Name: testzone.domain.ru
Address: 82.11.22.33
Name: testzone.domain.ru
Address: 77.11.22.33
nslookup testzone.domain.ru ns1.domain.ru
Server: ns1.domain.ru
Address: 78.xx.xx.xx#53
Name: testzone.domain.ru
Address: 77.11.22.33
Name: testzone.domain.ru
Address: 82.11.22.33
nslookup testzone.domain.ru ns1.domain.ru
Server: ns1.domain.ru
Address: 78.xx.xx.xx#53
Name: testzone.domain.ru
Address: 82.11.22.33
Name: testzone.domain.ru
Address: 77.11.22.33
Ну вот и все :)
Источник: http://www.zytrax.com/books/dns/ch9/rr.html#services
Активация Routed Network на Xen Server
Узнаем имя бридж интерфейса, используемого XenServer`ом:
В ответ будет выдано примерно следующее:
Отсюда берем, что имя нашего бридж-интерфейса - xenbr0.
Далее создаем интерфейс, который будет играть роль шлюза для подсети (пример дается для имени интефрейса xenbr0):
Со следующим содержимым:
Таким образом, на указанном IP адресе у нас расположится шлюз, который нужно будет указывать для машин, которым выдан IP адрес из подсети, чтобы сеть на них заработала.
Активируем форвардинг пакетов:
Применяем настройки ядра:
Заменяем там:
Конфигурируем фаерволлл:
Там после строки "-A RH-Firewall-1-INPUT -i lo -j ACCEPT" добавляем:
Применяем настройки фаерволла:
Поднимаем интерфейс:
После этого назначаем стандартную сеть вновь создаваемым виртуальным машинам и указываем для них стандартным шлюзом первый используемый IP адрес из сети (см. выше).
После этого все же стоит перезагрузить машинку, на случай, если что-то все же не применилось корректно.
Источник: http://support.citrix.com/article/CTX120964
route | grep default
В ответ будет выдано примерно следующее:
default static.1.22.63. 0.0.0.0 UG 0 0 0 xenbr0
Отсюда берем, что имя нашего бридж-интерфейса - xenbr0.
Далее создаем интерфейс, который будет играть роль шлюза для подсети (пример дается для имени интефрейса xenbr0):
vi /etc/sysconfig/network-scripts/ifcfg-xenbr0:1
Со следующим содержимым:
DEVICE=xenbr0:1
ONBOOT=yes
BOOTPROTO=none
NETMASK=тут_маска_доп_сети
IPADDR=тут_первый_используемый_адрес_доп_сети
Таким образом, на указанном IP адресе у нас расположится шлюз, который нужно будет указывать для машин, которым выдан IP адрес из подсети, чтобы сеть на них заработала.
Активируем форвардинг пакетов:
vi /etc/sysctl.conf
Применяем настройки ядра:
sysctl -p
Заменяем там:
net.ipv4.ip_forward = 0На
net.ipv4.ip_forward = 1
Конфигурируем фаерволлл:
vi /etc/sysconfig/iptables
Там после строки "-A RH-Firewall-1-INPUT -i lo -j ACCEPT" добавляем:
-A RH-Firewall-1-INPUT -i xenbr0 -o xenbr0 -j ACCEPT
Применяем настройки фаерволла:
service iptables restart
Поднимаем интерфейс:
ifup xenbr0:1
После этого назначаем стандартную сеть вновь создаваемым виртуальным машинам и указываем для них стандартным шлюзом первый используемый IP адрес из сети (см. выше).
После этого все же стоит перезагрузить машинку, на случай, если что-то все же не применилось корректно.
Источник: http://support.citrix.com/article/CTX120964
Tuesday, 12 October 2010
Настройка AoE target и initiator в Debian 5 Lenny
Target
Включаем загрузку модуля ядра, необходимого для работы aoe, при загрузке системы и запускаем его:
Ставим софт для target:
Экспорт блочного устройства в сеть осуществляется вот такой командой:
Поэтому нам необходимо добавить ее в конфиг файл:
Чуть выше строки exit 0.
Теперь выполняем экспорт:
Теперь настроим клиентскую часть на другой машине.
Initiator
Ставим нужное ПО:
Теперь пробуем найти экспортированное устройство (команда ничего не выдает на экран, это нормально):
И после этого запрашиваем список доступных устройств (у меня машин без роутера посредине не нашлось, поэтому все тесты делались на локалхосте):
После этого в /dev у нас должна появиться интересная папка:
Где, /dev/etherd/e0.1 и есть наше экспортированное блочное устройство:
Теперь немного тестов, по аналогии с тестами iSCSI.
Рандомное чтение (этот тест не верный! запускался несколько раз, и разброс значений был: 5000, 12000, 11000, чем вызвано - не понимаю):
Рандомная запись (тут также бред, диск подключенный напрямую не дает и 3х тысяч, здесь же - больше):
Источник: http://www.howtoforge.com/using-ata-over-ethernet-aoe-on-debian-lenny-initiator-and-target
Включаем загрузку модуля ядра, необходимого для работы aoe, при загрузке системы и запускаем его:
echo "aoe" >> /etc/modules
modprobe aoe
Ставим софт для target:
apt-get install -y vblade
Экспорт блочного устройства в сеть осуществляется вот такой командой:
vbladed 0 1 eth0 /dev/sdd
Поэтому нам необходимо добавить ее в конфиг файл:
vi /etc/rc.local
Чуть выше строки exit 0.
Теперь выполняем экспорт:
/etc/rc.local
Теперь настроим клиентскую часть на другой машине.
Initiator
echo "aoe" >> /etc/modules
modprobe aoe
Ставим нужное ПО:
apt-get install -y aoetools
Теперь пробуем найти экспортированное устройство (команда ничего не выдает на экран, это нормально):
aoe-discover
И после этого запрашиваем список доступных устройств (у меня машин без роутера посредине не нашлось, поэтому все тесты делались на локалхосте):
aoe-stat
e0.1 128.035GB lo up
После этого в /dev у нас должна появиться интересная папка:
ls -la /dev/etherd/
total 0
drwxr-xr-x 2 root root 180 2010-10-12 07:44 .
drwxr-xr-x 17 root root 3.9K 2010-10-12 07:44 ..
c-w--w---- 1 root disk 152, 3 2010-10-12 07:44 discover
brw-rw---- 1 root disk 152, 16 2010-10-12 07:44 e0.1
brw-rw---- 1 root disk 152, 17 2010-10-12 07:44 e0.1p1
cr--r----- 1 root disk 152, 2 2010-10-12 07:44 err
c-w--w---- 1 root disk 152, 6 2010-10-12 07:44 flush
c-w--w---- 1 root disk 152, 4 2010-10-12 07:44 interfaces
c-w--w---- 1 root disk 152, 5 2010-10-12 07:44 revalidate
Где, /dev/etherd/e0.1 и есть наше экспортированное блочное устройство:
fdisk -l /dev/etherd/e0.1
Disk /dev/etherd/e0.1: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xe72f675d
Device Boot Start End Blocks Id System
/dev/etherd/e0.1p1 1 15566 125033894+ 83 Linux
Теперь немного тестов, по аналогии с тестами iSCSI.
Рандомное чтение (этот тест не верный! запускался несколько раз, и разброс значений был: 5000, 12000, 11000, чем вызвано - не понимаю):
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/etherd/e0.1 -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [2163K/0K /s] [4226/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=20708
read : io=42439KB, bw=2122KB/s, iops=4243, runt= 20001msec
slat (usec): min=8, max=246, avg=16.03, stdev= 7.21
clat (usec): min=25, max=396, avg=213.75, stdev=17.66
bw (KB/s) : min= 2082, max= 2178, per=100.05%, avg=2122.13, stdev=23.66
cpu : usr=3.48%, sys=5.86%, ctx=88762, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=84878/0, short=0/0
lat (usec): 50=0.12%, 100=0.01%, 250=97.77%, 500=2.11%
Run status group 0 (all jobs):
READ: io=42439KB, aggrb=2121KB/s, minb=2172KB/s, maxb=2172KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
etherd!e0.1: ios=84355/0, merge=0/0, ticks=17788/0, in_queue=0, util=88.95%
Рандомная запись (тут также бред, диск подключенный напрямую не дает и 3х тысяч, здесь же - больше):
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/etherd/e0.1 -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/854K /s] [0/1669 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=20719
write: io=167841KB, bw=8392KB/s, iops=16783, runt= 20001msec
slat (usec): min=4, max=144, avg=12.11, stdev= 5.01
clat (usec): min=0, max=46889, avg=43.56, stdev=408.41
bw (KB/s) : min= 61, max=34508, per=102.31%, avg=8584.82, stdev=10701.52
cpu : usr=11.18%, sys=16.32%, ctx=336579, majf=0, minf=14979
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/335682, short=0/0
lat (usec): 2=48.53%, 4=0.71%, 10=0.05%, 20=0.81%, 50=46.81%
lat (usec): 100=0.39%, 250=2.03%, 500=0.13%, 750=0.04%, 1000=0.02%
lat (msec): 2=0.05%, 4=0.06%, 10=0.36%, 20=0.01%, 50=0.01%
Run status group 0 (all jobs):
WRITE: io=167841KB, aggrb=8391KB/s, minb=8593KB/s, maxb=8593KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
etherd!e0.1: ios=0/335332, merge=0/0, ticks=0/12348, in_queue=0, util=61.75%
Источник: http://www.howtoforge.com/using-ata-over-ethernet-aoe-on-debian-lenny-initiator-and-target
Тестирование iSCSI поверх 100 мегабитной сети
Планируем использовать iSCSI для одного из проектов, поэтому решил его протестировать. Для начала, пожалуй, стоит проверить оверхед технологии самой по себе, то есть, запустить и target и initiator на одной машине.
Для тестов файловой системы мы привлечем утилиту fio, о ней я писал несколько дней назад: http://phpsuxx.blogspot.com/2010/10/linux-fio.html Также по ссылке можете найти 3 измерения производительности SSD диска, подключенного напрямую по протоколу SATA2. Теперь давайте измерим, как изменится скорость при доступе напрямую, но по протоколу iSCSI.
Рандомное чтение (было 10939; во время теста load average поднималось до 1-1,5):
Рандомная запись (было 2876; во время теста load average поднималось до 1-1,5):
Очень сложно как-то подытожить такие результаты, но второй тест показывает, что оверхеда нету вообще, а вот первый как будто упирается в какой-то лимит.
Теперь же проведем те же самые тесты, но с машины, подключенной к тому же коммутатору, что и наша тестовая. Связь между машинами работате вот с такой задержкой:
Рандомное чтение (на локалхост было 5800, стало по сети 1340; нагрузка на сеть при этом порядка 8 мегабит/с):
Рандомная запись (на локалхост было 2900, стало по сети 1964):
Итого резюмируя все выше сказанное можно сказать, что:
1) iSCSI прожорлив до проца (поднять до 1.5 la на i7 975 - это круто, угу)
2) iSCSI упирается в какой-то лимит Linux при очень большом IOPS чтения
3) Для подключения устройств с меньшим IOPS, чем у SSD (SAS, SATA), iSCSI подходит почти идеально.
4) Все же стоит еще посмотреть в сторону AoE, возможно, он позволит избавится от таких обвалов IOPS за счет своей легковесности.
У кого есть дополнения - прошу в комментарии.
Для тестов файловой системы мы привлечем утилиту fio, о ней я писал несколько дней назад: http://phpsuxx.blogspot.com/2010/10/linux-fio.html Также по ссылке можете найти 3 измерения производительности SSD диска, подключенного напрямую по протоколу SATA2. Теперь давайте измерим, как изменится скорость при доступе напрямую, но по протоколу iSCSI.
Рандомное чтение (было 10939; во время теста load average поднималось до 1-1,5):
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/sde -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [1874K/0K /s] [3661/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=19915
read : io=58185KB, bw=2909KB/s, iops=5818, runt= 20001msec
slat (usec): min=9, max=138, avg=13.30, stdev= 2.79
clat (usec): min=47, max=499, avg=153.16, stdev=75.35
bw (KB/s) : min= 1756, max= 4464, per=100.97%, avg=2937.15, stdev=1209.60
cpu : usr=5.22%, sys=9.74%, ctx=116459, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=116370/0, short=0/0
lat (usec): 50=0.01%, 100=31.24%, 250=51.24%, 500=17.52%
Run status group 0 (all jobs):
READ: io=58185KB, aggrb=2909KB/s, minb=2978KB/s, maxb=2978KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sde: ios=115918/0, merge=0/0, ticks=17248/0, in_queue=17240, util=86.21%
Рандомная запись (было 2876; во время теста load average поднималось до 1-1,5):
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/sde -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/1472K /s] [0/2875 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=19927
write: io=29647KB, bw=1482KB/s, iops=2964, runt= 20001msec
slat (usec): min=6, max=145, avg=15.62, stdev= 4.37
clat (usec): min=99, max=6877, avg=315.64, stdev=334.37
bw (KB/s) : min= 1412, max= 1640, per=100.06%, avg=1482.85, stdev=36.07
cpu : usr=3.24%, sys=5.72%, ctx=59324, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/59294, short=0/0
lat (usec): 100=0.01%, 250=72.39%, 500=19.53%, 750=2.68%, 1000=1.24%
lat (msec): 2=3.35%, 4=0.78%, 10=0.02%
Run status group 0 (all jobs):
WRITE: io=29647KB, aggrb=1482KB/s, minb=1517KB/s, maxb=1517KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sde: ios=0/58936, merge=0/0, ticks=0/17820, in_queue=17808, util=89.05%
Очень сложно как-то подытожить такие результаты, но второй тест показывает, что оверхеда нету вообще, а вот первый как будто упирается в какой-то лимит.
Теперь же проведем те же самые тесты, но с машины, подключенной к тому же коммутатору, что и наша тестовая. Связь между машинами работате вот с такой задержкой:
ping -c4 188.40.68.15
PING 188.40.68.15 (188.40.68.15) 56(84) bytes of data.
64 bytes from 188.40.68.15: icmp_seq=1 ttl=62 time=0.294 ms
64 bytes from 188.40.68.15: icmp_seq=2 ttl=62 time=0.430 ms
64 bytes from 188.40.68.15: icmp_seq=3 ttl=62 time=0.301 ms
64 bytes from 188.40.68.15: icmp_seq=4 ttl=62 time=0.364 ms
--- 188.40.68.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.294/0.347/0.430/0.056 ms
Рандомное чтение (на локалхост было 5800, стало по сети 1340; нагрузка на сеть при этом порядка 8 мегабит/с):
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdd -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [690K/0K /s] [1349/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=5378
read : io=13406KB, bw=686352B/s, iops=1340, runt= 20001msec
slat (usec): min=13, max=53, avg=25.26, stdev= 1.75
clat (usec): min=379, max=1040, avg=716.82, stdev=51.30
bw (KB/s) : min= 666, max= 686, per=100.10%, avg=670.69, stdev= 3.50
cpu : usr=0.62%, sys=5.42%, ctx=53626, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=26812/0, short=0/0
lat (usec): 500=0.43%, 750=76.95%, 1000=22.61%
lat (msec): 2=0.01%
Run status group 0 (all jobs):
READ: io=13406KB, aggrb=670KB/s, minb=686KB/s, maxb=686KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sdd: ios=26648/0, merge=0/0, ticks=19032/0, in_queue=19024, util=95.14%
Рандомная запись (на локалхост было 2900, стало по сети 1964):
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdd -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/1011K /s] [0/1975 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=5347
write: io=19644KB, bw=982KB/s, iops=1964, runt= 20001msec
slat (usec): min=19, max=153, avg=34.11, stdev= 5.27
clat (usec): min=307, max=1183, avg=467.78, stdev=47.46
bw (KB/s) : min= 901, max= 999, per=100.04%, avg=982.44, stdev=23.28
cpu : usr=1.24%, sys=7.92%, ctx=78595, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/39287, short=0/0
lat (usec): 500=87.68%, 750=12.26%, 1000=0.06%
lat (msec): 2=0.01%
Run status group 0 (all jobs):
WRITE: io=19643KB, aggrb=982KB/s, minb=1005KB/s, maxb=1005KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sdd: ios=0/39039, merge=0/0, ticks=0/18896, in_queue=18880, util=94.42%
Итого резюмируя все выше сказанное можно сказать, что:
1) iSCSI прожорлив до проца (поднять до 1.5 la на i7 975 - это круто, угу)
2) iSCSI упирается в какой-то лимит Linux при очень большом IOPS чтения
3) Для подключения устройств с меньшим IOPS, чем у SSD (SAS, SATA), iSCSI подходит почти идеально.
4) Все же стоит еще посмотреть в сторону AoE, возможно, он позволит избавится от таких обвалов IOPS за счет своей легковесности.
У кого есть дополнения - прошу в комментарии.
Как подружить ocfs2 и CentOS 5 ?
Так понимаю, для этого нужно подключить спец-репозитории от Oracle: http://oss.oracle.com/projects/ocfs2/
А вот и лаконичный мануал по сабжу: http://engwar.com/post/328
А вот и лаконичный мануал по сабжу: http://engwar.com/post/328
Что такое кластерные файловые системы и в чем их ключевое отличие от обычных файловых систем?
Давно изучал эту тему, но никак не доходили руки написать что-то целостное. Итак, что же такое кластерная файловая система? Крайне просто - это файловая система, которая примонтирована в нескольких местах.
Пытливый читатель сразу задаст логичный вопрос - как можно один дисковый носитель подключить к несколькими ПК? Разумеется, домашнее железо такого не умеет, а вот серверные SCSI массивы вполне так умеют. Также к вариантам подключения одного носителя к нескольким ПК стоит отнести всевозможные транспортные протоколы типа iSCSI и AoE, которые позволяют экспортировать блочное устройство в сеть и выполнить его подключение к нескольким машинам.
Итак, допустим, у нас есть некое блочное устройство, подключенное к двум серверам по какому-то из перечисленных выше интерфейсов. Допустим, на носителе существовала некая классическая файловая система (скажем, ext3) и мы смогли смонтировать ее на запись на обоих узлах (обращаю внимание, что случай абстрактный, возможно, то, что я описываю сделать невозможно).
Теперь же давайте подумаем, что будет, если два узла попытаются одновременно обратиться к одним и тем же секторам на носителе с попыткой что-либо туда записать? А получиться может все, что угодно - данные запишутся частично от одного узла, частично от другого; один из узлов перепишет данные записанные другим и т.д. Разумеется, что это приведет к тому, что файловая система как минимум потребует проверки своей структуры (fsck), а как максимум полностью выйдет из строя. Очевидно, оба случая фатальны, так как для исправления возникших проблем нужно отключать файловую систему.
Как же победить эту проблему? Тут нам на помощь приходит страшная штука по имени DLM, а расшифровывается она как Distributed Lock Manager. Что же это значит и как работает? Во-первых, работает он на всех узлах, где смонтирована файловая система, во-вторых, DLM, запущенные на всех узлах, обмениваются между собой информацией посредством сети. А суть этого механизма в том, что он позволяет координировать между собой операции, которые могут повлечь за собой конкурентный доступ к какому-либо ресурсу файловой системы или накопителя. То есть, в приведенном выше примере первый узел захватил бы блокировку на запись, начал делать, что ему нужно, в это же время второй узел смиренно бы ждал своей очереди и после этого бы сделал все, что ему требуется. Как результат всей этой операции мы имеем целостную файловую систему и никаких противоречивых изменений.
Итак, какие же кластерные файловые системы существуют? Во-первых, это, конечно же, GFS (GFS2) от RedHat и OCFS2 от Oracle. Также сюда, пожалуй, стоит отнести Lustre (хотя она ко всему прочему еще и распределенная).
Источник: http://en.wikipedia.org/wiki/Clustered_file_system
Пытливый читатель сразу задаст логичный вопрос - как можно один дисковый носитель подключить к несколькими ПК? Разумеется, домашнее железо такого не умеет, а вот серверные SCSI массивы вполне так умеют. Также к вариантам подключения одного носителя к нескольким ПК стоит отнести всевозможные транспортные протоколы типа iSCSI и AoE, которые позволяют экспортировать блочное устройство в сеть и выполнить его подключение к нескольким машинам.
Итак, допустим, у нас есть некое блочное устройство, подключенное к двум серверам по какому-то из перечисленных выше интерфейсов. Допустим, на носителе существовала некая классическая файловая система (скажем, ext3) и мы смогли смонтировать ее на запись на обоих узлах (обращаю внимание, что случай абстрактный, возможно, то, что я описываю сделать невозможно).
Теперь же давайте подумаем, что будет, если два узла попытаются одновременно обратиться к одним и тем же секторам на носителе с попыткой что-либо туда записать? А получиться может все, что угодно - данные запишутся частично от одного узла, частично от другого; один из узлов перепишет данные записанные другим и т.д. Разумеется, что это приведет к тому, что файловая система как минимум потребует проверки своей структуры (fsck), а как максимум полностью выйдет из строя. Очевидно, оба случая фатальны, так как для исправления возникших проблем нужно отключать файловую систему.
Как же победить эту проблему? Тут нам на помощь приходит страшная штука по имени DLM, а расшифровывается она как Distributed Lock Manager. Что же это значит и как работает? Во-первых, работает он на всех узлах, где смонтирована файловая система, во-вторых, DLM, запущенные на всех узлах, обмениваются между собой информацией посредством сети. А суть этого механизма в том, что он позволяет координировать между собой операции, которые могут повлечь за собой конкурентный доступ к какому-либо ресурсу файловой системы или накопителя. То есть, в приведенном выше примере первый узел захватил бы блокировку на запись, начал делать, что ему нужно, в это же время второй узел смиренно бы ждал своей очереди и после этого бы сделал все, что ему требуется. Как результат всей этой операции мы имеем целостную файловую систему и никаких противоречивых изменений.
Итак, какие же кластерные файловые системы существуют? Во-первых, это, конечно же, GFS (GFS2) от RedHat и OCFS2 от Oracle. Также сюда, пожалуй, стоит отнести Lustre (хотя она ко всему прочему еще и распределенная).
Источник: http://en.wikipedia.org/wiki/Clustered_file_system
Что такое eSATA?
Очень просто - это внешний (externalSATA) интерфейс для подключения SATA устройств.
Производительность MySQL при работе на iSCSI массиве
Всем, кто заинтересован в сабже, рекомендую прочесть статью:
http://ralpartha.blogspot.com/2006/07/mysql-sysbench-benchmarking-iscsi.html
А вот больше технических подробностей теста: http://ralpartha.blogspot.com/2006/07/more-info-on-iscsi-benchmark.html
А вот результаты внедрения в продакшене: http://ralpartha.blogspot.com/2007/02/mysql-and-iscsi-winning-combo.html
А вот комментарии специалистов на mysqlperformanceblog: http://www.mysqlperformanceblog.com/2006/07/06/sysbench-evaluation-of-iscsi-performance/
Я понимаю, что многие заголовок посчитают бредом сумасшедшего, но прошу прочесть статьи по ссылкам :)
http://ralpartha.blogspot.com/2006/07/mysql-sysbench-benchmarking-iscsi.html
А вот больше технических подробностей теста: http://ralpartha.blogspot.com/2006/07/more-info-on-iscsi-benchmark.html
А вот результаты внедрения в продакшене: http://ralpartha.blogspot.com/2007/02/mysql-and-iscsi-winning-combo.html
А вот комментарии специалистов на mysqlperformanceblog: http://www.mysqlperformanceblog.com/2006/07/06/sysbench-evaluation-of-iscsi-performance/
Я понимаю, что многие заголовок посчитают бредом сумасшедшего, но прошу прочесть статьи по ссылкам :)
Сражения искусственных интеллектов: Google AI Challenge
Вот наводка для адептов Перла: http://green-kakadu.livejournal.com/29414.html :)
SciFinder - новости науки со всего света!
http://www.cas.org/products/sfacad/index.html
SciFinder is a research discovery tool that allows college students and faculty to access a wide diversity of research from many scientific disciplines, including biomedical sciences, chemistry, engineering, materials science, agricultural science, and more!
Monday, 11 October 2010
Pgpool против PgBouncer
Вот отличный тест, сравнивающий их в продакшен окружении: http://www.lastfm.ru/user/Russ/journal/2008/02/21/zd_postgres_connection_pools:_pgpool_vs._pgbouncer
Что такое Hadoop?
Всегда думал, что это некий децентрализованный сторадж. Оказалось, нет - это целый комплект утилит и технологий (децентрализованная файловая система, распределенное ключ-ориентированное хранилище, реализация mapreduce, софт по контролю за распределенным инсталляциями и многое другое) для high load / high performance систем: http://hadoop.apache.org/#What+Is+Hadoop%3F
Sunday, 10 October 2010
Настройка iSCSI initiator на Debian 6 Squeeze
Теперь попробуем поставить инициатор и подключиться к нашему устройству:
И добавляем в самый верх конфига:
Следующее (это есть данные для аутентификации на таргете, аутентификацию таргета мы не осуществляем):
И чуточку ниже корректируем настройки запуска для автозапуска (не забывая убрать node.startup = manual):
Подгружаем клиент-демон:
Все, теперь пробуем сделать discovery, чтобы обнаружить наш экспортированный SSD (-p задает IP адрес портала, -m задает тип операции):
Выполняем логин:
После этого в системе появится еще одно блочное устройство:
После этого я с легкостью (как будто это мой диск в компьютере) запустил команду fdisk, создал логический раздел на удаленном устройстве и создал на нем файловую систему.
Для того, чтобы отключить его делаем logout:
О настройке серверной части читайте в другой статье: http://phpsuxx.blogspot.com/2010/10/iscsi-target-debian-5-lenny-x8664.html
Источник initiator: http://wiki.debian.org/SAN/iSCSI/open-iscsi
apt-get install -y open-iscsi
И добавляем в самый верх конфига:
vi /etc/iscsi/iscsid.conf
Следующее (это есть данные для аутентификации на таргете, аутентификацию таргета мы не осуществляем):
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = joe
discovery.sendtargets.auth.password = YourSecurePwd1
node.session.auth.authmethod = CHAP
node.session.auth.username = joe
node.session.auth.password = YourSecurePwd1
И чуточку ниже корректируем настройки запуска для автозапуска (не забывая убрать node.startup = manual):
node.startup = automatic
Подгружаем клиент-демон:
/etc/init.d/open-iscsi start
Все, теперь пробуем сделать discovery, чтобы обнаружить наш экспортированный SSD (-p задает IP адрес портала, -m задает тип операции):
iscsiadm -m discovery -t st -p 127.0.0.1
127.0.0.1:3260,1 iqn.2012-03.ru.fastvps.storage:storage1
xx.yy.zz.kk:3260,1 iqn.2012-03.ru.fastvps.storage:storage1
Выполняем логин:
iscsiadm -m node --targetname "iqn.2012-03.ru.fastvps.storage:storage1" --portal "127.0.0.1:3260" --login
Logging in to [iface: default, target: iqn.2012-03.ru.fastvps.storage:storage1, portal: 127.0.0.1,3260]
Login to [iface: default, target: iqn.2012-03.ru.fastvps.storage:storage1, portal: 127.0.0.1,3260]: successful
После этого в системе появится еще одно блочное устройство:
dmesg | tail -15
[62342.477969] Loading iSCSI transport class v2.0-870.
[62342.484054] iscsi: registered transport (tcp)
[62342.500410] iscsi: registered transport (iser)
[62424.188944] scsi9 : iSCSI Initiator over TCP/IP
[62425.189703] scsi 9:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[62425.189820] sd 9:0:0:0: Attached scsi generic sg11 type 0
[62425.189913] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
[62425.189952] sd 9:0:0:0: [sdd] 23404216320 512-byte logical blocks: (11.9 TB/10.8 TiB)
[62425.189992] sd 9:0:0:0: [sdd] Write Protect is off
[62425.189993] sd 9:0:0:0: [sdd] Mode Sense: 77 00 00 08
[62425.190063] sd 9:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[62425.190165] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
[62425.190292] sdd: unknown partition table
[62425.190696] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
[62425.190885] sd 9:0:0:0: [sdd] Attached SCSI disk
После этого я с легкостью (как будто это мой диск в компьютере) запустил команду fdisk, создал логический раздел на удаленном устройстве и создал на нем файловую систему.
Для того, чтобы отключить его делаем logout:
iscsiadm -m node --targetname "iqn.2012-03.ru.fastvps.storage:storage1" --portal "127.0.0.1:3260" --logout
Logging out of session [sid: 1, target: iqn.2012-03.ru.fastvps.storage:storage1, portal: 127.0.0.1,3260]
Logout of [sid: 1, target: iqn.2012-03.ru.fastvps.storage:storage1, portal: 127.0.0.1,3260]: successful
О настройке серверной части читайте в другой статье: http://phpsuxx.blogspot.com/2010/10/iscsi-target-debian-5-lenny-x8664.html
Источник initiator: http://wiki.debian.org/SAN/iSCSI/open-iscsi
Saturday, 9 October 2010
Настройка iSCSI target на Debian 6 Squeeze x86_64
Что такое iSCSI и зачем оно нужно: http://ru.wikipedia.org/wiki/ISCSI
Ставим пакет служебных программ, а также модуль ядра (собирается автоматически при обновлении ядра):
Активируем запуск iSCSI target:
Указываем там следующее:
Я планирую экспортировать по iSCSI блочное устройство /dev/sdc, так что
Теперь открываем главный конфиг-файл:
Теперь в самый низ добавляем следующие строки:
Для начала стоит объяснить, что запись "iqn.2012-03.ru.fastvps.storage" представляет собой уникальное имя iSCSI target. Как можно заметить, в самом начале всегда "iqn", потом год и месяц создания домена и некий сабдомен (допустим, поддомен в домене всех сторадж-серверов), записанный в обратном формате. storage1 просто является дополнительным идентификатором.
IncomingUser предназначен для аутентификации iSCSI инициатора. А OutgoingUser предназначен для аутентификации самого сервера (target) на инициатор. Пароли при этом должны быть ровно 12 символов.
На последней строке идентифицируется устройство, которое мы экспортируем и режим (кроме fileio доступен blockio - прямой ввод/вывод с избежанием страничного кэша, подробнее об их отличиях можно прочесть man ietd.conf).
Все, запускаем:
Убеждаемся, что модуль ядоа зацепился:
А также смотрим dmesg:
Как видим, наш демон забиндился на 3260й порт:
О настройке инициатора (клиентской части) читайте в другом посте: http://phpsuxx.blogspot.com/2010/10/iscsi-initiator-debian-5-lenny.html
Источник target: http://wiki.debian.org/iSCSI/iscsitarget
Ставим пакет служебных программ, а также модуль ядра (собирается автоматически при обновлении ядра):
apt-get install -y iscsitarget iscsitarget-dkms
Активируем запуск iSCSI target:
vi /etc/default/iscsitarget
Указываем там следующее:
ISCSITARGET_ENABLE=true
Я планирую экспортировать по iSCSI блочное устройство /dev/sdc, так что
Теперь открываем главный конфиг-файл:
vi /etc/iet/ietd.conf
Теперь в самый низ добавляем следующие строки:
Target iqn.2012-03.ru.fastvps.storage:storage1
IncomingUser joe YourSecurePwd1
OutgoingUser jim YourSecurePwd2
Lun 0 Path=/dev/sdc,Type=fileio
Для начала стоит объяснить, что запись "iqn.2012-03.ru.fastvps.storage" представляет собой уникальное имя iSCSI target. Как можно заметить, в самом начале всегда "iqn", потом год и месяц создания домена и некий сабдомен (допустим, поддомен в домене всех сторадж-серверов), записанный в обратном формате. storage1 просто является дополнительным идентификатором.
IncomingUser предназначен для аутентификации iSCSI инициатора. А OutgoingUser предназначен для аутентификации самого сервера (target) на инициатор. Пароли при этом должны быть ровно 12 символов.
На последней строке идентифицируется устройство, которое мы экспортируем и режим (кроме fileio доступен blockio - прямой ввод/вывод с избежанием страничного кэша, подробнее об их отличиях можно прочесть man ietd.conf).
Все, запускаем:
/etc/init.d/iscsitarget start
Убеждаемся, что модуль ядоа зацепился:
lsmod|grep iscsi_trgt
iscsi_trgt 69353 4
А также смотрим dmesg:
dmesg|tail -4
[61850.263686] iSCSI Enterprise Target Software - version 1.4.20.2
[61850.263746] iscsi_trgt: Registered io type fileio
[61850.263748] iscsi_trgt: Registered io type blockio
[61850.263749] iscsi_trgt: Registered io type nullio
Как видим, наш демон забиндился на 3260й порт:
netstat -lnpt | grep 3260
tcp 0 0 0.0.0.0:3260 0.0.0.0:* LISTEN 7169/ietd
tcp6 0 0 :::3260 :::* LISTEN 7169/ietd
О настройке инициатора (клиентской части) читайте в другом посте: http://phpsuxx.blogspot.com/2010/10/iscsi-initiator-debian-5-lenny.html
Источник target: http://wiki.debian.org/iSCSI/iscsitarget
FreeBSD 8.1 и ZFS: cannot remove ad14: only inactive hot spares or cache devices can be removed
Имеем вот такой конфиг с 1 slog устройством:
И при попытке удалить slog устройство ad14 получаем:
Судя по рассылке ZFS, форуму OpenSolaris и форуму FreeBSD это баг и единственный вариант избавится от slog`а - это удалить массив.
P.S. log устройства во FreeBSD 8.1 использовать КРАЙНЕ не рекомендуется. Кроме невозможности их удаления есть еще одна неприятность - если log-устройство было создано не как mirror, а как одиночное устройство, то в случае его отказа становится недоступным весь пул с данными и как это исправлять у меня информации нету.
zpool status
pool: backup
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad10 ONLINE 0 0 0
logs ONLINE 0 0 0
ad14 ONLINE 0 0 0
errors: No known data errors
И при попытке удалить slog устройство ad14 получаем:
zpool remove backup ad14
cannot remove ad14: only inactive hot spares or cache devices can be removed
Судя по рассылке ZFS, форуму OpenSolaris и форуму FreeBSD это баг и единственный вариант избавится от slog`а - это удалить массив.
P.S. log устройства во FreeBSD 8.1 использовать КРАЙНЕ не рекомендуется. Кроме невозможности их удаления есть еще одна неприятность - если log-устройство было создано не как mirror, а как одиночное устройство, то в случае его отказа становится недоступным весь пул с данными и как это исправлять у меня информации нету.
Механизмы кэширования ZFS: ARC и L2ARC
Я думаю, многим известно, что ZFS отличается очень большим числом крайне интересных функций. Кэширование не стало исключением - тут у ZFS есть в арсенале целых два механизма: ARC и L2ARC.
Почему они так странно называются, ARC? Эти кэши получили свое название в честь алгоритма кэширования, на котором они основаны, алгоритма ARC, кроме него также широко распространен LRU, но ARC считается более производительным.
ARC - это кэш ZFS, расположенный в оперативной памяти, L2ARC - его продолжение (Layer 2, второй уровень), но на более медленном, чем оперативная память носителе (но при этом обладающим бОльшим объемом) и в то же время, более быстром, чем диски самого массива. Обычно, в роли носителей для L2ARC используются SSD диски, так как их скорости чтения/записи с легкостью превосходят последние модели SAS.
Говоря об абстрактных вещах, таких как кэши, тем не менее сложно не оглядываться в практическую сторону - да, SSD диски хороши при чтении данных, это они делают ну очень быстро, но пи этом далеко не у всех SSD носителей хорошо обстоят дела со скоростями записи. Не станет ли при этом запись в кэш тормозить непосредственно чтение? Нет, не будет, запись в кэши в ZFS происходит асинхронно и никак не может повлиять на чтение с ZFS.
Как же это работает на деле?
Наполнение кэша: при чтении, данные, к которым идет наиболее частый доступ, помещаются в ARC кэш, со временем он переполняется и данные из ARC кэша вытесняются в L2ARC кэш до лучших времен и лишь после этого удаляются совсем.
Использование кэша: при попытке прочесть данные с диска, ZFS сначала ищет их в оперативной памяти (ARC), если там необходимые данные отсутствуют, то выполняется попытка найти их в L2ARC кэше и лишь в случае неудачи на этом шаге будет выполнено реальное чтение с физического устройства.
Многие могут заметить - а не проще ли создать огромный ARC кэш, ведь оперативная память крайне дешева? Нет, не проще, крайне проблематично поставить на сервер, скажем, 256 гигабайт памяти под кэш массива тб на 150 :)
Как было сказано выше, в первую очередь эти кэши используется при чтении и как раз при нем дают максимальный эффект, но как быть при записи? Ведь нельзя долго складировать данные в памяти, иначе это чревато их потерей при потере питания (а вот для ZFS это абсолютно безопасно - она не пострадает, просто данные не будут записаны и все, консистеность же файловой системы будет вне угрозы). На этот случай (для ускорения операций записи) в ZFS также имеется технология кэширования (но не данных, а транзакций), которая именуется ZIL. Но об этом я напишу в отдельном посте.
А вот небольшая заметка про реальное увеличение скорости за счет использования L2ARC: http://www.zfsbuild.com/2010/07/30/testing-the-l2arc/ и вот заметка про увеличение скорости работы MySQL: http://blogs.sun.com/cs/entry/improving_mysql_innodb_zfs_read
Источники: http://blogs.sun.com/brendan/entry/test и http://www.zfsbuild.com/2010/04/15/explanation-of-arc-and-l2arc/
Почему они так странно называются, ARC? Эти кэши получили свое название в честь алгоритма кэширования, на котором они основаны, алгоритма ARC, кроме него также широко распространен LRU, но ARC считается более производительным.
ARC - это кэш ZFS, расположенный в оперативной памяти, L2ARC - его продолжение (Layer 2, второй уровень), но на более медленном, чем оперативная память носителе (но при этом обладающим бОльшим объемом) и в то же время, более быстром, чем диски самого массива. Обычно, в роли носителей для L2ARC используются SSD диски, так как их скорости чтения/записи с легкостью превосходят последние модели SAS.
Говоря об абстрактных вещах, таких как кэши, тем не менее сложно не оглядываться в практическую сторону - да, SSD диски хороши при чтении данных, это они делают ну очень быстро, но пи этом далеко не у всех SSD носителей хорошо обстоят дела со скоростями записи. Не станет ли при этом запись в кэш тормозить непосредственно чтение? Нет, не будет, запись в кэши в ZFS происходит асинхронно и никак не может повлиять на чтение с ZFS.
Как же это работает на деле?
Наполнение кэша: при чтении, данные, к которым идет наиболее частый доступ, помещаются в ARC кэш, со временем он переполняется и данные из ARC кэша вытесняются в L2ARC кэш до лучших времен и лишь после этого удаляются совсем.
Использование кэша: при попытке прочесть данные с диска, ZFS сначала ищет их в оперативной памяти (ARC), если там необходимые данные отсутствуют, то выполняется попытка найти их в L2ARC кэше и лишь в случае неудачи на этом шаге будет выполнено реальное чтение с физического устройства.
Многие могут заметить - а не проще ли создать огромный ARC кэш, ведь оперативная память крайне дешева? Нет, не проще, крайне проблематично поставить на сервер, скажем, 256 гигабайт памяти под кэш массива тб на 150 :)
Как было сказано выше, в первую очередь эти кэши используется при чтении и как раз при нем дают максимальный эффект, но как быть при записи? Ведь нельзя долго складировать данные в памяти, иначе это чревато их потерей при потере питания (а вот для ZFS это абсолютно безопасно - она не пострадает, просто данные не будут записаны и все, консистеность же файловой системы будет вне угрозы). На этот случай (для ускорения операций записи) в ZFS также имеется технология кэширования (но не данных, а транзакций), которая именуется ZIL. Но об этом я напишу в отдельном посте.
А вот небольшая заметка про реальное увеличение скорости за счет использования L2ARC: http://www.zfsbuild.com/2010/07/30/testing-the-l2arc/ и вот заметка про увеличение скорости работы MySQL: http://blogs.sun.com/cs/entry/improving_mysql_innodb_zfs_read
Источники: http://blogs.sun.com/brendan/entry/test и http://www.zfsbuild.com/2010/04/15/explanation-of-arc-and-l2arc/
Бойтесь данайцев дары приносящих
Всегда скептически относился к электронным сервисам РЖД, чуя подвох, и всегда забирал реальные (не электронные) билеты за пару дней до поездки, как оказалось, не зря - у РЖД попросту нету инструкций, как быть, если по каким-то причинам откажет оборудование по выдаче взамен электронных тех самых реальных билетов: http://glipatova.livejournal.com/29523.html
Friday, 8 October 2010
FreeBSD: No manual entry for ls
Как бороться с такой напастью? Нужно поставить man страницы. Делается это не совсем тривиально, читаем дальше.
Запускаем sysinstall:
Далее выбираем "Configure Do post-install configuration of FreeBSD", далее "Distributions Install additional distribution sets", далее ставим галочки на "man" и "info" и жмем "Ok". После этого в новом окошке появляется окошко выбора источника установки, выбираем "2 FTP Install from an FTP server", далее выбираем какой-нибудь зеркало из блока "Primary" и нажимаем ок, потом подтверждаем наличие сетевого соединения. Все, ждем пока маны будут установлены и выходим из sysinstall.
Более подробно и с картинками: http://www.cyberciti.biz/tips/howto-install-man-info-pages-and-other-package-set.html
Запускаем sysinstall:
sysinstall
Далее выбираем "Configure Do post-install configuration of FreeBSD", далее "Distributions Install additional distribution sets", далее ставим галочки на "man" и "info" и жмем "Ok". После этого в новом окошке появляется окошко выбора источника установки, выбираем "2 FTP Install from an FTP server", далее выбираем какой-нибудь зеркало из блока "Primary" и нажимаем ок, потом подтверждаем наличие сетевого соединения. Все, ждем пока маны будут установлены и выходим из sysinstall.
Более подробно и с картинками: http://www.cyberciti.biz/tips/howto-install-man-info-pages-and-other-package-set.html
Установка утилиты arcconf для Adaptec 5405 на Debian 5 Lenny Linux
Вполне возможна, даже есть официальные (но минимально протестированные!) сборки StorMan для Debian/Ubuntu: здесь.
Инструкцию по установке:
Отключаем stor agent и выключаем его автозапуск:
Также ставим библиотеку, необходимую для работы arcconf:
Пробуем запустить arcconf:
Инструкцию по установке:
cd /usr/src
wget http://download.adaptec.com/tmp0001/adaptec/asmdeb/asm_debian_x86_x64_v6_50_18570.tgz
tar -xf asm_debian_x86_x64_v6_50_18570.tgz
# 64 бита
dpkg -i storman_6.50-18570_amd64.deb
# 32 бита
dpkg -i storman_6.50-18570_i386.deb
Отключаем stor agent и выключаем его автозапуск:
/etc/init.d/stor_agent stop
update-rc.d -f stor_agent remove
Также ставим библиотеку, необходимую для работы arcconf:
apt-get install -y libstdc++5
Пробуем запустить arcconf:
/usr/StorMan/arcconf getversion 1
Controllers found: 1
Controller #1
==============
Firmware : 5.2-0 (17899)
Staged Firmware : 5.2-0 (17899)
BIOS : 5.2-0 (17899)
Driver : 1.1-5 (2461)
Boot Flash : 5.2-0 (17899)
Command completed successfully.
Возможно ли использование сторонних SSD носителей для подключения к Adaptec MaxIQ кэшу?
Да, если у Вас Adaptec контроллер Q серии (модели начального уровня стоят от $400).
Источник: база знаний Adaptec.
Источник: база знаний Adaptec.
Как получить доступ к сайту, пока DNS еще не обновились?
Если Вы используете Windows 2000 / XP, то необходимо блокнотом открыть файл:
И добавить там строку:
C:\WINDOWS\system32\drivers\etc\hosts
И добавить там строку:
new.ip.addr.es domain.ru
Как очистить DNS кэш в Windows?
ipconfig /flushdns
Что будет с данными, если вдруг откажет MaxIQ SSD кэш диск?
Ничего!
(с) http://www.adaptec.com/en-US/products/CloudComputing/MaxIQ/SSD-Cache-Performance/_resources/SSD_FAQs.htm?nc=/en-US/products/CloudComputing/MaxIQ/SSD-Cache-Performance/_resources/SSD_FAQs.htm
With MaxIQ, all the data gets first written to the RAID rotating media, protecting the data in case the SSD cache pool fails.
(с) http://www.adaptec.com/en-US/products/CloudComputing/MaxIQ/SSD-Cache-Performance/_resources/SSD_FAQs.htm?nc=/en-US/products/CloudComputing/MaxIQ/SSD-Cache-Performance/_resources/SSD_FAQs.htm
Измерение производительности дисковой подсистемы в Linux посредством утилиты fio
Давно ломал голову над вопросом объективного тестирования файловой системы, но никаких адекватных утилит для этого не попадалось. И вот, читая статью про IOPS, наткнулся упоминание утилиты fio. Официальный сайт утилиты находится по адресу: http://freshmeat.net/projects/fio
Как показал беглый осмотр репозиториев (как CentOS, таки Debian), утилиты там нету, поэтому будем собирать из исходников.
Ставим зависимости в случае CentOS:
Или в случае Debian:
Собираем:
В случае FreeBSD 8.1 установка чуть проще:
Все, утилита собрана и теперь ее можно запускать вот так:
Итак, теперь можно потестить свою дисковую подсистему и сравнить с эталонами (ряд значений есть в вики статье: http://en.wikipedia.org/wiki/IOPS).
Попробуем протестировать скорость случайного чтения:
Далее я провожу тесты для пары своих железок, для начала это массив: RAID-10 на Adaptec 5405 из 4x SAS 15k SEAGATE ST3300657SS.
В ответ будет выдано что-то примерно следующее (интересующее нас поле IOPS я выделил):
Если же изменить iodepth до 24 (опять же, это взято с вики), то результаты получатся чуть иные:
А вот тест на рандомную запись на RAID-10 SAS:
Далее тест чтения для одного SSD диска SuperTalent UltraDrive GX SSD STT_FTM28GX25H 128 Gb:
Если же изменить iodepth до 24:
Теперь тест на скорость рандомной записи тоже для SSD (обращаю внимание, данные на носителе при этом тесте будут уничтожены!):
Далее тест чтения для одного SSD диска Corsair CSSD-F12 (Corsair Force Series F120 - CSSD-F120GB2), firmware 1.1:
И тест записи на нем же:
Далее тесты на запись на SATA2 ST31500341AS 7200rpm (данные на диске при этом будут уничтожены!):
Опять же для SATA2 на чтение:
SATA2 на чтение, depth=24:
Программный RAID-1 из SATA дисков, рандомная запись:
Итого, резюмирую:
Более подробное описание параметров и типов теста можно найти в файле HOWTO, он лежит в папке рядом с бинариком.
Как показал беглый осмотр репозиториев (как CentOS, таки Debian), утилиты там нету, поэтому будем собирать из исходников.
Ставим зависимости в случае CentOS:
yum install -y make gcc libaio-devel
Или в случае Debian:
apt-get install -y gcc make libaio-dev
Собираем:
cd /usr/src
wget http://brick.kernel.dk/snaps/fio-2.0.6.tar.gz
tar -xf fio-2.0.6.tar.gz
cd fio-2.0.6
make
В случае FreeBSD 8.1 установка чуть проще:
cd /usr/ports/sysutils/fio
make install clean
rehash
Все, утилита собрана и теперь ее можно запускать вот так:
/usr/src/fio-2.0.6/fio
Итак, теперь можно потестить свою дисковую подсистему и сравнить с эталонами (ряд значений есть в вики статье: http://en.wikipedia.org/wiki/IOPS).
Попробуем протестировать скорость случайного чтения:
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/sda -ioengine libaio -direct=1
Далее я провожу тесты для пары своих железок, для начала это массив: RAID-10 на Adaptec 5405 из 4x SAS 15k SEAGATE ST3300657SS.
В ответ будет выдано что-то примерно следующее (интересующее нас поле IOPS я выделил):
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [101K/0K /s] [198/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=15183
read : io=2,024KB, bw=101KB/s, iops=202, runt= 20003msec
slat (usec): min=11, max=40, avg=22.55, stdev= 3.29
clat (usec): min=59, max=11,462, avg=4912.37, stdev=1475.76
bw (KB/s) : min= 92, max= 112, per=99.90%, avg=100.90, stdev= 3.60
cpu : usr=0.16%, sys=0.52%, ctx=4049, majf=0, minf=21
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=4047/0, short=0/0
lat (usec): 100=0.10%, 250=0.05%
lat (msec): 2=1.38%, 4=28.19%, 10=70.20%, 20=0.07%
Run status group 0 (all jobs):
READ: io=2,023KB, aggrb=101KB/s, minb=103KB/s, maxb=103KB/s, mint=20003msec, maxt=20003msec
Disk stats (read/write):
sda: ios=4027/2, merge=0/5, ticks=19782/1, in_queue=19783, util=98.70%
Если же изменить iodepth до 24 (опять же, это взято с вики), то результаты получатся чуть иные:
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=24
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [568K/0K /s] [1K/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=15264
read : io=10,035KB, bw=500KB/s, iops=999, runt= 20074msec
slat (usec): min=6, max=97, avg=23.53, stdev= 4.45
clat (usec): min=45, max=968K, avg=23958.61, stdev=37772.28
bw (KB/s) : min= 0, max= 573, per=64.60%, avg=322.34, stdev=242.21
cpu : usr=0.78%, sys=2.87%, ctx=18892, majf=0, minf=24
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued r/w: total=20070/0, short=0/0
lat (usec): 50=0.01%, 100=0.02%, 250=0.03%
lat (msec): 2=0.21%, 4=7.71%, 10=38.74%, 20=22.52%, 50=19.02%
lat (msec): 100=7.61%, 250=3.76%, 500=0.32%, 750=0.04%, 1000=0.01%
Run status group 0 (all jobs):
READ: io=10,035KB, aggrb=499KB/s, minb=511KB/s, maxb=511KB/s, mint=20074msec, maxt=20074msec
Disk stats (read/write):
sda: ios=19947/2, merge=0/5, ticks=475887/21, in_queue=476812, util=99.26%
А вот тест на рандомную запись на RAID-10 SAS:
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/sda1 -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/652K /s] [0/1275 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=2815
write: io=12759KB, bw=653202B/s, iops=1275, runt= 20001msec
slat (usec): min=12, max=89, avg=15.77, stdev= 1.01
clat (usec): min=260, max=40079, avg=765.22, stdev=777.73
bw (KB/s) : min= 499, max= 721, per=100.16%, avg=638.00, stdev=33.64
cpu : usr=0.52%, sys=2.02%, ctx=25529, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/25517, short=0/0
lat (usec): 500=47.21%, 750=19.48%, 1000=6.87%
lat (msec): 2=24.44%, 4=1.38%, 10=0.54%, 20=0.07%, 50=0.02%
Run status group 0 (all jobs):
WRITE: io=12758KB, aggrb=637KB/s, minb=653KB/s, maxb=653KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sda: ios=0/25385, merge=0/0, ticks=0/19604, in_queue=19604, util=98.03%
Далее тест чтения для одного SSD диска SuperTalent UltraDrive GX SSD STT_FTM28GX25H 128 Gb:
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdd -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [5602K/0K /s] [11K/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=5993
read : io=109399KB, bw=5470KB/s, iops=10939, runt= 20001msec
slat (usec): min=8, max=169, avg= 9.52, stdev= 2.47
clat (usec): min=1, max=375, avg=78.44, stdev= 8.10
bw (KB/s) : min= 5442, max= 5486, per=100.03%, avg=5470.54, stdev= 7.93
cpu : usr=5.98%, sys=13.00%, ctx=218950, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=218797/0, short=0/0
lat (usec): 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.14%
lat (usec): 100=98.83%, 250=1.01%, 500=0.01%
Run status group 0 (all jobs):
READ: io=109398KB, aggrb=5469KB/s, minb=5600KB/s, maxb=5600KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sdd: ios=217551/0, merge=0/0, ticks=16620/0, in_queue=16580, util=82.91%
Если же изменить iodepth до 24:
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 24 -filename /dev/sdd -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=24
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [14589K/0K /s] [28K/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=5999
read : io=284442KB, bw=14221KB/s, iops=28442, runt= 20001msec
slat (usec): min=2, max=336, avg= 6.83, stdev= 5.36
clat (usec): min=264, max=1691, avg=832.82, stdev=129.85
bw (KB/s) : min=14099, max=14300, per=100.00%, avg=14220.82, stdev=35.28
cpu : usr=14.04%, sys=25.98%, ctx=323599, majf=0, minf=28
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued r/w: total=568884/0, short=0/0
lat (usec): 500=0.01%, 750=29.74%, 1000=59.18%
lat (msec): 2=11.07%
Run status group 0 (all jobs):
READ: io=284442KB, aggrb=14221KB/s, minb=14562KB/s, maxb=14562KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sdd: ios=565467/0, merge=0/0, ticks=469940/0, in_queue=469896, util=99.39%
Теперь тест на скорость рандомной записи тоже для SSD (обращаю внимание, данные на носителе при этом тесте будут уничтожены!):
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdd -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/1447K /s] [0/2828 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=6006
write: io=28765KB, bw=1438KB/s, iops=2876, runt= 20001msec
slat (usec): min=10, max=151, avg=16.01, stdev= 2.75
clat (usec): min=28, max=4387, avg=326.63, stdev=266.13
bw (KB/s) : min= 1359, max= 1659, per=100.20%, avg=1440.92, stdev=50.97
cpu : usr=2.24%, sys=5.56%, ctx=57682, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/57530, short=0/0
lat (usec): 50=0.25%, 100=0.01%, 250=20.55%, 500=76.71%, 750=0.60%
lat (usec): 1000=0.39%
lat (msec): 2=0.72%, 4=0.77%, 10=0.01%
Run status group 0 (all jobs):
WRITE: io=28765KB, aggrb=1438KB/s, minb=1472KB/s, maxb=1472KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sdd: ios=0/57207, merge=0/0, ticks=0/18264, in_queue=18264, util=91.33%
Далее тест чтения для одного SSD диска Corsair CSSD-F12 (Corsair Force Series F120 - CSSD-F120GB2), firmware 1.1:
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/sda -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [1728K/0K /s] [3376/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=4193
read : io=33676KB, bw=1684KB/s, iops=3367, runt= 20001msec
slat (usec): min=7, max=45, avg=12.74, stdev= 0.58
clat (usec): min=138, max=9325, avg=281.76, stdev=66.69
bw (KB/s) : min= 1655, max= 1691, per=100.07%, avg=1684.26, stdev= 9.71
cpu : usr=1.16%, sys=3.54%, ctx=67374, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=67352/0, short=0/0
lat (usec): 250=1.35%, 500=98.63%, 750=0.01%
lat (msec): 10=0.01%
Run status group 0 (all jobs):
READ: io=33676KB, aggrb=1683KB/s, minb=1724KB/s, maxb=1724KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sda: ios=66945/0, merge=0/0, ticks=19392/0, in_queue=19392, util=97.00%
И тест записи на нем же:
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdc -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/1418K /s] [0/2771 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=4251
write: io=33458KB, bw=1673KB/s, iops=3345, runt= 20001msec
slat (usec): min=12, max=472, avg=13.43, stdev= 1.89
clat (usec): min=1, max=31361, avg=282.93, stdev=347.25
bw (KB/s) : min= 1034, max= 2454, per=100.54%, avg=1680.95, stdev=459.33
cpu : usr=1.98%, sys=5.36%, ctx=66945, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/66915, short=0/0
lat (usec): 2=0.01%, 250=36.63%, 500=59.59%, 750=1.57%, 1000=0.57%
lat (msec): 2=1.50%, 4=0.12%, 10=0.01%, 20=0.01%, 50=0.01%
Run status group 0 (all jobs):
WRITE: io=33457KB, aggrb=1672KB/s, minb=1712KB/s, maxb=1712KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sda: ios=0/66550, merge=0/0, ticks=0/19080, in_queue=19060, util=95.34%
Далее тесты на запись на SATA2 ST31500341AS 7200rpm (данные на диске при этом будут уничтожены!):
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdc -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/54K /s] [0/107 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=7118
write: io=1163KB, bw=59542B/s, iops=116, runt= 20001msec
slat (usec): min=14, max=140, avg=16.29, stdev= 3.23
clat (usec): min=449, max=35573, avg=8566.41, stdev=6411.62
bw (KB/s) : min= 44, max= 108, per=99.91%, avg=57.95, stdev=10.26
cpu : usr=0.16%, sys=0.24%, ctx=2335, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/2326, short=0/0
lat (usec): 500=0.26%, 750=12.90%, 1000=6.49%
lat (msec): 2=0.47%, 4=3.44%, 10=37.75%, 20=34.35%, 50=4.34%
Run status group 0 (all jobs):
WRITE: io=1163KB, aggrb=58KB/s, minb=59KB/s, maxb=59KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
sdc: ios=0/2325, merge=0/0, ticks=0/19884, in_queue=19892, util=98.24%
Опять же для SATA2 на чтение:
/usr/src/fio-1.41/fio -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/sdc -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [33K/0K /s] [66/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=7130
read : io=662016B, bw=33085B/s, iops=64, runt= 20009msec
slat (usec): min=13, max=125, avg=15.18, stdev= 4.09
clat (msec): min=3, max=30, avg=15.44, stdev= 4.20
bw (KB/s) : min= 28, max= 37, per=99.20%, avg=31.74, stdev= 1.93
cpu : usr=0.22%, sys=0.12%, ctx=1302, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=1293/0, short=0/0
lat (msec): 4=0.08%, 10=9.20%, 20=76.57%, 50=14.15%
Run status group 0 (all jobs):
READ: io=646KB, aggrb=32KB/s, minb=33KB/s, maxb=33KB/s, mint=20009msec, maxt=20009msec
Disk stats (read/write):
sdc: ios=1290/0, merge=0/0, ticks=19884/0, in_queue=19900, util=98.28%
SATA2 на чтение, depth=24:
/usr/src/fio-1.41/fio -name iops -rw=randread -bs=512 -runtime=20 -iodepth 24 -filename /dev/sdc -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=24
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [65K/0K /s] [128/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=7135
read : io=1230KB, bw=62274B/s, iops=121, runt= 20217msec
slat (usec): min=2, max=35, avg= 8.72, stdev= 1.28
clat (msec): min=13, max=907, avg=196.69, stdev=126.43
bw (KB/s) : min= 0, max= 67, per=64.52%, avg=38.71, stdev=29.17
cpu : usr=0.40%, sys=0.06%, ctx=2464, majf=0, minf=28
IO depths : 1=0.1%, 2=0.1%, 4=0.2%, 8=0.3%, 16=99.4%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued r/w: total=2459/0, short=0/0
lat (msec): 20=0.20%, 50=4.15%, 100=19.44%, 250=48.80%, 500=24.68%
lat (msec): 750=2.56%, 1000=0.16%
Run status group 0 (all jobs):
READ: io=1229KB, aggrb=60KB/s, minb=62KB/s, maxb=62KB/s, mint=20217msec, maxt=20217msec
Disk stats (read/write):
sdc: ios=2456/0, merge=0/0, ticks=480380/0, in_queue=481280, util=98.21%
Программный RAID-1 из SATA дисков, рандомное чтение:
/usr/src/fio-1.41/fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 1 -filename /dev/md1 -ioengine libaio -direct=1
iops: (g=0): rw=randread, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [70K/0K /s] [137/0 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=3647
read : io=1,406KB, bw=71,958B/s, iops=140, runt= 20001msec
slat (usec): min=0, max=4,001, avg=31.31, stdev=352.56
clat (usec): min=0, max=204K, avg=7079.63, stdev=5615.73
bw (KB/s) : min= 40, max= 79, per=99.96%, avg=69.97, stdev= 6.46
cpu : usr=0.00%, sys=0.34%, ctx=5624, majf=0, minf=26
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=2811/0, short=0/0
lat (usec): 2=5.80%
lat (msec): 10=77.45%, 20=16.47%, 50=0.18%, 100=0.04%, 250=0.07%
Run status group 0 (all jobs):
READ: io=1,405KB, aggrb=70KB/s, minb=71KB/s, maxb=71KB/s, mint=20001msec, maxt=20001msec
Disk stats (read/write):
md1: ios=2782/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
sdb: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
Программный RAID-1 из SATA дисков, рандомная запись:
/usr/src/fio-1.41/fio -name iops -rw=randwrite -bs=512 -runtime=20 -iodepth 1 -filename /dev/md0 -ioengine libaio -direct=1
iops: (g=0): rw=randwrite, bs=512-512/512-512, ioengine=libaio, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [w] [100.0% done] [0K/105K /s] [0/205 iops] [eta 00m:00s]
iops: (groupid=0, jobs=1): err= 0: pid=3650
write: io=2,089KB, bw=104KB/s, iops=208, runt= 20004msec
slat (usec): min=0, max=192K, avg=103.42, stdev=3007.66
clat (usec): min=0, max=880K, avg=4680.69, stdev=31246.53
bw (KB/s) : min= 3, max= 243, per=108.77%, avg=113.12, stdev=52.21
cpu : usr=0.06%, sys=0.20%, ctx=8347, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/4177, short=0/0
lat (usec): 2=27.60%
lat (msec): 4=9.50%, 10=60.14%, 20=2.61%, 1000=0.14%
Run status group 0 (all jobs):
WRITE: io=2,088KB, aggrb=104KB/s, minb=106KB/s, maxb=106KB/s, mint=20004msec, maxt=20004msec
Disk stats (read/write):
md0: ios=0/4130, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
sdb: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
Итого, резюмирую:
RAID-10 на Adaptec 5405 из 4x SAS 15k SEAGATE ST3300657SS (2 магнитных диска)
random read, depth=1: 202 IOPS
random read, depth=24: 999 IOPS
random write, depth=1: 1275 IOPS
RAID-10 на LSI MR9260-4i из 4x SAS 15k SEAGATE ST3300657SS (2 магнитных диска)
random read, depth=1: 200 IOPS
random read, depth=24: 1011 IOPS
random write, depth=1: 1148 IOPS
RAID-1 на LSI MR9260-4i из 2x SAS 15k SEAGATE ST3300657SS (2 магнитных диска)
random read, depth=1: 218 IOPS
random read, depth=24: 887 IOPS
random write, depth=1: 624 IOPS
RAID-5 на LSI MR9260-4i из 3x SAS 15k SEAGATE ST3300657SS (2 магнитных диска)
random read, depth=1: 167 IOPS
random read, depth=24: 878 IOPS
random write, depth=1: 631 IOPS
RAID-0 на LSI MR9260-4i из 2x SAS 15k SEAGATE ST3300657SS (2 магнитных диска)
random read, depth=1: 160 IOPS
random read, depth=24: 504 IOPS
random write, depth=1: 987 IOPS
SSD диск SuperTalent UltraDrive GX SSD STT_FTM28GX25H 128 Gb
random read, depth=1: 10939 IOPS
random read, depth=24: 28442 IOPS
random write, depth=1: 2876 IOPS
SATA2 ST31500341AS 7200rpm
random read, depth=1: 64 IOPS
random read, depth=24: 121 IOPS
random write, depth=1: 116 IOPS
VPS
random read, depth=1: 126 IOPS
random write,depth=1: 236 IOPS
Adaptec 5805 RAID 10 8 SATA 3Tb WD Green
random read, depth=1: 87 IOPS
random read, depth=24: 431 IOPS
random write, depth=1: 186 IOPS
random write, depth=24: 193 IOPS
Adaptec 5805 RAID 10 8 SATA 3Tb WD Green over 1Gbps iSCSI without Jumbo frames
random read, depth=1: 60 IOPS
random read, depth=24: 320 IOPS
random write, depth=1: 187 IOPS
random write, depth=24: 192 IOPS
Adaptec 2405 Velociraptor WD1000DHTZ-0 x 2 RAID-1:
random read, depth=1: 160 IOPS
random read, depth=24: 545 IOPS
random write, depth=1: 140 IOPS
random write, depth=24: 140 IOPS
Adaptec 2405 Seagate ST3600057SS 15000 600Gb (4 магнитных диска) x 2 RAID-1:
random read, depth=1: 205 IOPS
random read, depth=24: 650 IOPS
random write, depth=1: 375 IOPS
random write, depth=24: 385 IOPS
Более подробное описание параметров и типов теста можно найти в файле HOWTO, он лежит в папке рядом с бинариком.
Subscribe to:
Posts
(
Atom
)