Текущая версия на 15:08, 30 октября 2013

Один из плюсов конференции был в том, что рекламные доклады в основном были отделены от нормальных. Первый день вообще — второй зал это была чистая реклама (даже «Предотвращение HTTP DDoS атак»), первый — нормальные люди. Самое забавное, что слова, от которых лично у меня вянут уши — «решение», «внедрение», «доставка приложений» — являются практически 100 % точными признаками рекламы. Прекрасно.

В основном у докладчиков презентации были вменяемые вполне, плохо рассказывал тоже мало кто, некоторые вообще откровенно жгли :) воспринималось всё нормально. В целом — «зачёт!».

Из минусов своего посещения — в понедельник не выдержал, не дождался послушать Завалишина с его «Фантом ОС», было любопытно, что же этот фрик скажет («200—400 % увеличение длины… то есть производительности труда разработчика! файлы больше сохранять не надо!…» и т.п). Также обидно за блиц-доклады, но не дождался, не закайфовал там до 20:30 сидеть, отвалил домой. А во вторник таки попал на 2 или 3 рекламных доклада, но у меня с собой был ноутбук, поэтому я их спокойно пропустил мимо ушей, занимаясь чем-то своим.

День первый (13.04.2009, понедельник)

Тюнинг FreeBSD 7.0 (зачёт!)

«Первый докладчик у нас — Игорь Сысоев, все вы вероятно знаете nginx, вот, это человек, который его написал в качестве хобби». Доклад про то, как оптимизировать FreeBSD-сервер для, фактически, отдачи статики. Ну или динамики, но такой динамики, что в процессор никто не упирается, а узкое место — только сеть. Доклад хороший, много раз повторённый много где (имеет долгую выдержку :)), в данном случае адаптированный к FreeBSD 7. В процессе заодно немножко рассказал про устройство сети во FreeBSD.

Тюнинг — в двух словах это sysctl’и:

• tcbhashsize (только в конфиг бутлоадера),
• maxsockets: помним что 1 сокет = 1800 байт ядра,
• somaxconn: netstat -Lan — посмотреть,
• maxfiles: каждый дескриптор = 128 байт ядра,
• openfiles,
• nmbcluster: мембуф кластеры по 2 Кб ядра,
• recvspace: буфер отправки,
• recvbuf_auto,
• maxfilesperproc,
• nmbjumbop: по 4Кб,
• sendspace,
• sendbuf_auto,
• sendbuf_inc,
• sendbuf_max,
• maxtcptw: должно быть < maxsockets.

Ещё vm.kmem_size (объём памяти ядра, здесь у 7-ки как раз преимущество — до 5Гб вместо до 1.5Гб), maxvnodes.

Длинные имена sysctl’ек я не писал, но всё найти можно sysctl -a | grep что-нибудь. Смысл простой, у многих из этих параметров значения по умолчанию маловаты и в них довольно легко упереться. Одновременно, правда, нужно помнить что на каждое подключение создаётся сокет, файловый дескриптор, мембуф кластер, буфер отправки, буфер приёма. Если будут слишком большие лимиты, можно легко и память ядра выжрать всю.

Также упомянул про sendfile и то, что его нужно использовать, так как в смысле передачи файла в сокет оптимальнее его ничего и быть не может. Nginx умеет, да. :) Кстати, если кто не знает, nginx — это такая штука, которая умеет очень многое из того, что умеет Апач (и кое-что, что апач не умеет), но умеет это со скоростью thttpd.

Рассказал про дополнительные хинты:

• отказаться от фаерволов! особенно, если они не нужны, так как это lock’и. Попробовать заменить их /etc/hosts.allow, а уж если нужно забанить «плохих людей», можно им прописать route на 127.0.0.1.
• если в top видно swi1, наткнулись на слабое место — непараллельный (по процам/ядрам) TCP/IP. Можно попробовать поиграться с параметрами intr_queue_maxlen и isr.direct.
• небольшой хинт для PostgreSQL: shm_use_phys = 1. + С постгресом лучше юзать фрю 7.2, так как там есть хак для поддержки сегментов разделяемой памяти SysV > 2 Гб.

OpenBSD — сетевая подсистема в деталях (незачёт!)

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

«Метки, метки… Да, что же хотелось сказать о метках?… Ну в целом ничего…»

«А когда по вашему будет IPv6?» — «IPv6, IPv6, IPv6 это threat, ну то есть он ещё не доделан, ну то есть в OpenBSD он уже работает… Но не доделан. Ещё года 3 точно не будет» :) по-видимому, речь была о том, когда же IPv6 станет широко распространён, а не про то, когда же он появится в OpenBSD.

Эффективное управление ПО по *nix (незачёт!)

«Доклад делится на две части — мечтательно-теоретическую и практическую». Практической не было.

Вышел какой-то чувак, начал рассказывать про то что да, сейчас все воспринимают управление ПО под *nix как install-update-remove, а это, он считает, неправильно, просто все привыкли. И что на самом деле нужны возможности многоверсионных, многоinstanceовых инсталляций (одновременно несколько версий пакета/пакетов без конфликтов), что нужны возможности !! при установке !! распределять между приложениями ресурсы… Проц, память, дошёл даже до того, чтобы распределять !! экранное пространство !! при установке… «Ну то есть это в общем-то то, что уже более серьёзно поддерживается… Ну то есть портами это не поддерживается…», вспомнил про ресурс «доверие», типа может быть вы вот этой ЭЦП доверяете, но не совсем! Тогда при установке вы и программе доступ к нужным вещам дадите, но не совсем :) правда тут тоже мол уже есть — домены безопасности.

В общем, ИМХО основные идеи притянуты за уши. Многоверсионные инсталляции — это ещё хорошо, хотя и может провоцировать тучу глюков (бывает всё-таки необходимо). Это да. Но вот про распределение проца, памяти и особенно экранного пространства при установке… Уж это совсем.

Обзор особенностей OpenSolaris (зачёт!)

В целом доклад про ZFS, про виртуализацию (контейнеры), про DTrace, про IPS. Из Санок (Sun) пришёл замечательный чувак, весьма интересно рассказывал, адекватно отвечал на вопросы, спровоцировал большие обсуждения в кулуарах (это больше к Мише Ларину, кулуары он пас). :) Пришёл, говорит ну у кого у вас здесь на ноуте/дома стоит OpenSolaris? Ну, в общем, ни у кого, ну и логично, да. :)

«А как выглядит OpenSolaris? Внешне он очень похож на Linux — ГНОМ он и в Африке ГНОМ…»

«Новые функции появляются в OpenSolaris!» («…этот ZFS хочешь ты, юный падаван…»)

Какие же новые функции? Distribution constructor (то есть сборка своего дистра / LiveCD), Bluetooth и USB-принтеры (ну да, наконец-то! а он говорит — ну логично, ну кому на сервере нужны USB-принтеры?..), Crossbow — виртуализация сетевых интерфейсов, IPS — новая систему управления пакетами для OpenSolaris, созданная автором APT’а (Debian) — Яном Мердоком, и потому на apt вполне похожая… При этом солярные вкусности все остаются, например Trusted extensions (снабжение всех данных метками секретности, и более секретные данные сунуть в менее секретные никак не получится, хоть клипбордой, хоть на печать вывести за пределы охраняемой амбалами-с-дубинками комнаты).

Про ZFS. Кто не знает — ZFS = Zettabyte filesystem, ФС хорошая, аналогов мало/нет, есть классные фичи, плюс Санками придумана гениальная совершенно лицензия, делающая ZFS совместимой с *BSD, но несовместимой с GPL (в лице Linux). Что в некотором плане логично, так как если бы она была совместима с Linux, то появилась бы там мгновенно и солярка стала бы «нинужна совсем» © аналитики ЛОРа. В частности мужик подробно рассказал про «древовидные контрольные суммы», когда в родительском блоке хранятся чексуммы всех дочерних — а зачем это надо? А затем, что ZFS стали использовать в CERN’е — это те ребята, которые БАК построили. А кроме того, что бомбоубежищаколлайдеры строить, они ещё занимаются всяким матмоделированием, у них огромные объёмы данных, а важны координаты каждой молекулы. И вот ещё до ZFS они решили посмотреть и проверить, а сколько же у них данных сначала пишется, а потом читается, но неправильно? Оказалось что это где-то 0.01 %, и это их совсем не порадовало <подозреваю, что у них были битые харды/контроллеры — прим.вред>, с коими и борется ZFS чексуммами и возможностью указать количество копий данных, которые надо записывать на диск вместо одной копии, причём физически на диске разнося подальше. Чтобы если одна окажется по чексумме битая, то из другой всё возьмётся, перезапишется и ничего не потеряется.

Про зоны/контейнеры. Это не виртуализация, хотя и позволяет поднять на одной машине много тазиков и в них резвиться. Солярные зоны, кстати, имеют такой «+» — создав специальную зону/контейнер, в ней можно запускать Linux-приложения, и будет линух внутри солярки. Кроме этого технология очень похожа на Virtuozzo / OpenVZ, детище Параллелей (бывший SWSoft) — об этом кто-то задал вопрос, в итоге чего вышел параллелист (Кирилл Колышкин) и сказал что «Да, Действительно Они Очень Похожи, Но у Нас Лучше.» :) в общем, тем кто не знает — это не виртуализация, а запуск нескольких копий операционки на основе одного ядра, но при этом в изолированных «пространствах» (к другим доступ сможет иметь максимум привилегированный домен, существующий в единственном экземпляре). Опять-таки для тех, кто не знает — Virtuozzo используют практически все платные хостинги в качестве услуги «VDS»/«VPS» (виртуальный выделенный сервер). Очень распространённая вещь. Вот и солярные зоны — это что-то типа.

Ещё мужик показал небольшое live demo, запустил-остановил контейнер, показал виртуальные сетевые интерфейсы, виртуальные роутеры.

…почему Windows 7 быстро работает? (нейтрально)

Не ставлю ни «зачёт», ни «незачёт», отношение нейтральное, так как доклад рассказан нормально, но особо интересного ничего нет, и на вопросы докладчик не ответил, так как ничего, кроме текста доклада, не знал. Краткий ответ на «почему?» — потому, что в M$ наконец-то удосужились запустить профилировщик (профилировали в основном десктопные задачи типа «нажатие на кнопку пуск»), выкинуть GDI и заменить его DirectDraw, выкинуть 49 ненужных служб, стартовавших при запуске системы всегда (яркий пример — Tablet Input Service на системах без планшета/тачскрина), и сделать их старт по необходимости (TriggerStart — старт по событиям типа подключение/отключение устройства, назначение/снятие IP адреса, вход/выход из/в домена, политики, ETW (Event tracing for Windows) и т. п.). Из менее тривиального — сделали объединение таймеров во время idle, чтобы объединить близкие таймеры и дать процессору побольше отдохнуть.

Хвала изобретателям нетбуков. А может, и не хвала: виндекапец, похоже, опять откладывается.

PowerShell (нейтрально)

Начало многообещающее. «Ну, Microsoft уже не первый раз разрабатывает скриптовый язык…»

Докладчик — Большая Гипножаба. Ещё один доклад без «зачёта» и без «низачёта». Чувак-ренегат, вроде довольно известный на каких-то кодинг и юних форумах, бывший UNIXоид, но теперь работает в M$… Продажная тварь :) первые 5-10 минут его основной задачей было просто отбиться от всего ржача и стёба из зала.

«Это такой унифицированный интерфейс… Если PowerShell где-то запускается, то он там уже точно работает одинаково везде вместе со всеми компонентами… Где? Ну где, это в общем все новейшие ОС от M$» <ну да, понятно, на всех виндах работает, большое достижение>

Итак, ключевая мысль PowerShell’а… Отойти от кучи интерфейсов конфигурирования — WMI, ADSI, COM, .NET, и заменить одним, тру-православным. Причём создатели PowerShell’а утверждают что «любят POSIX», и стараются делать алиасы для команд типа cp mv ls mkdir rm и т. п. При этом они решили заменить текстовый обмен между программами на объектный — программы поддерживающие PowerShell, друг в друга кидаются .NET-объектами, и символ '|' (pipe) соединяет именно объектные ввод и вывод. Плюс на всех окошках конфигурирования появляется кнопочка, нажав на которую, можно получить powershell-скрипт из того, что сейчас делал.

Команды в PowerShell тяжёлые, синтаксис длинный. Алиасы команд-то есть, а вот для многих опций вариантов нет. ИМХО в качестве командной строки оно неудобно примерно в той же мере, в которой в качестве cmd неудобен перл, питон или ещё кто-нибудь. Кстати, про перл/питон кто-то из зала вспомнил… А чувак в ответ вспомнил любимую питонистами-перлоненавистниками фразу «перл — это язык write-only, то есть нечитаемый» <могу всех порадовать, лично я перлист, и язык читаемый, но синтаксис гибкий, поэтому тех кто такое не понимает, оно пугает (короче ИМХО кто ниасилил перл — ССЗБ)>. Но сам факт, что и C# 3.0 и PowerShell уже кому-то напоминают перл/пхп, чего-нибудь, да значит. С моей точки зрения, значит то, что всё так и идёт в сторону скорости разработки, скриптовых языков и ленивости программиста.

«Чтобы разработка была быстрой. Это возможно в ущерб скорости».

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

Безопасность Интернет-проектов: основные проблемы разработки и пути решений (нейтрально)

В некотором смысле уникальный доклад! :) уникален он тем, что был в первый день во втором зале, при этом почти не реклама, только немного рассказали про то, что у них есть «Web Application Firewall» и группа контроля безопасности. Вторую сессию Большой ГипноЖабы я слушать не хотел (опасно, а то вот затянут так в M$…) и пошёл именно на этот доклад.

Итак, доклад этот от PHP-быдлокодеров (1C, Bitrix) про тупые ошибки безопасности и про то, как часто люди их делают. Пример гениального клиента 1С: вообще в битриксе пароль в открытом виде в базе не хранится. Но кто-то из клиентов решил, что «им удобнее по телефону пароль сказать клиенту», и что бы вы думали?! Добавил свойство пользователя — «пароль», и записывали туда открытый пароль. Не говоря уже о том, что поле никакого особого статуса не имело.

Современный сайт — это обычно набор запчастей <поддерживаю мнение всеми руками и ногами, на PHP всегда так и есть>. Здесь сайт, здесь один писал, здесь другой, здесь третий, а здесь WordPress, а здесь форум… Всё это ещё как-то живо за счёт «security by obscurity» — у нас всё безопасно, так как мы даже сами не знаем, где у нас чего, а не то что взломщики.

Основные дыры, как всегда — это Cross-site scripting (XSS), SQL injection, PHP including, кража сессий из /tmp, внедрение чего-нибудь куда-нибудь в php-скрипт. Чувак рассказал про то, что у них сначала была мысль — блин, ну давайте хорошо учить веб-разработчиков — ошибки тупые, неужели нельзя натренировать людей, чтобы их не делали? И через 4-5 лет поняли, что нельзя, хотя текучки персонала почти нет — те же самые ошибки совершают те же самые кодеры, что и 5 лет назад.

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

Потом придумали свой Web Application Firewall и отдельно ядро (типа безопасное), фаервол — призван блокировать именно простые, как правило, автоматизированные, попытки взлома. Ну, типа, помогает. Когда запустили у себя — удивились, сколько попыток взлома идёт постоянно, взлома тупого и бессмысленного, но при этом всё равно опасного. Да, про это тоже говорили — 90 % взломов — автоматическими инструментами и «кулхацкерами», которые просто балуются, не понимая, что, вообще говоря, делают. Остальные 10 % — только на заказ, только за деньги, только тёмными личностями, которые нигде не светятся, не палятся, и вообще живут тихо. Таких иногда ловят. В принципе, наши исполнительные власти сами по себе мало что могут, но если им помогут те, кто умеет — кое-что уже могут.

А, ещё сказали про хороший способ улучшения безопасности, правда, работающий только 1 раз: сказать своим программистам, что заказали платный аудит у серьёзной фирмы, начнётся через неделю, и если что-то найдут — будут жертвы. :) до минимального уровня подтягивается сразу — это точно.

Короче ИМХО (я со всей этой фигнёй знаком прекрасно, на PHP писал): все эти «самые распространённые» проблемы — проблемы выбора языка разработки. PHP — Армянский Комсомол. Люди решают проблемы и не знают, что у других людей этих проблем просто нет!

Потому что сами создаём проблемы, а потом занимаемся с ними долгим и нудным сексом и не можем их решить, причём не просто не можем решить, а в глобальном масштабе не можем решить! Нет популярной реализации типа DBI (Perl) со строгой рекомендацией использовать bind-переменные («?»), а не интерполировать значения прямо в текст запроса? Нет taint mode (тоже Perl) и необходимости фильтровать и метить все данные, пришедшие извне, как безопасные? Нет нормального use / import / кому что больше нравится, а есть идиотский механизм include / require скриптов с возможностью включения скрипта лежащего на другом сервере? Нет нормального способа хранить сессии в базе (bitrix кстати это, в итоге, осилил — тоже мне, достижение)? Вот и получайте свои проблемы со своей безопасностью…

HA-кластер своими руками (нейтрально)

Чувак рассказывал немножко так, будто каждое слово застревало где-то по пути и его приходилось тяжко корчевать… Тема, в принципе интересная, но доклад — очень краткий обзор основного софта и протоколов для обеспечения фэйловера. Со всем этим чувак плотно явно не работал, а просто ставил и игрался. Но игрался точно.

Linux IPVS. Via NAT (шлюз) / via Direct Routing (у всех виртуальный IP кластера) / via IP tunneling (географическое распределение серверов). Полезно использовать firewall marks, например для группы протоколов HTTP+HTTPS.

wikipedia:VRRP и wikipedia:Common Address Redundancy Protocol. Первое — Сиськовская (Cisco) реализация протокола высокой доступности роутера. Второе — его свободный аналог, есть во фре, да и в linux тоже, но не только для роутеров. Смысл — один горячий, принимает запросы, второй холодный — heartbeat’ит горячий (- ты тут? — я тут — ты тут? — я тут… — ты тут? — … - ааа! сдох! поднимаюсь!). Название CARP наводит на то, что он как-то связан с ARP, и это верно — пока горячий жив, холодный на ARP-запросы «who-has <ip>» не отвечает, так как отвечает именно горячий, а как только горячий падает, на точно такие же ARP-запросы начинает отвечать холодный, и становится горячим. CARP — штука хорошая, говорю это по личному опыту — работал с ним на vsem.ru. Фаерволы (внешние сервера) у нас именно так и держали там общий IP, и фэйловер прекрасно работал. Собственно на CARP + pfsyncd можно сделать и балансировку нагрузки, правда, только round-robin (простую циклическую).

Дальше — это проекты Keepalive (VRRP, C, нет гуя, нет IPv6), HA-Linux (есть гуй на питоне), Pirahna (творение редхат, есть веб-гуй, CentOS).

Ещё он упомянул про GFS (гугл фс — кластерная), OCFS2 (ещё одна кластерная ФС — сделана для Oracle RAC ораклистами), DRBD (Distributed Replicated Block Device — распределённое реплицируемое блочное устройство), iSCSI (платное, сановское) и т. п. Это с точки зрения организации хранилища для кластера.

Архитектура и особенности эксплуатации кластера dns-реcолверов в крупном ISP (зачёт!)

Хороший, познавательный, доклад про опыт эксплуатации bind 8, bind 9 и unbound >= 1.2.1 в СТРИМе (да, докладчик был из стрима). Понятно, что каждый ISP в какой-то момент сталкивается с необходимостью организации некоего кластера ресолверов, так как запросов туча… У них это был 2004 год.

Итак, СТРИМ: 2 кластера по 6 серверов и по 2 балансировщика. Пиковая нагрузка за день ~22000 qps (запросов в секунду), % попаданий в кэш — 80-85 % (причём, чтобы добиться принципиально меньшего или большего значения, Нужно Очень Сильно Постараться — по сути это просто характеристика нагрузки). Софт: ресолвер unbound 1.2.1 (а раньше был BIND), dnstop и dns_flood_detector для выявления флуда, snmpd и cfengine для управления.

Что такое BIND (Berkeley Internet Namespace Daemon): наиболее популярный ресолвер. Известный, легко конфигурируемый, даёт приемлемую производительностью. В нём за всю историю Находили Много Дыр. Имеет некие проблемы с управлением памятью — очистка кэша (в смысле сборка мусора) происходит медленно, с большой загрузкой CPU и в это время сервер DNS практически «лежит», производительность снижается буквально до десятков запросов в секунду. Но при этом жить с ним можно, СТРИМ долгое время вполне себе жил, выявив оптимальные настройки кэша — максимальный TTL кэша ~ 1 час, принудительная сборка мусора каждые ~ 15 минут. От тормозов спасались просто: временным исключением соответствующего сервера из балансировки.

Что такое unbound: молодой проект. Версия 1.0 была 20 мая 2008 года. Примерно в 3 раза быстрее, чем BIND (даёт ~21000 qps в пике против ~6000-7000 бинда). Сложнее и гибче в конфигурации, пока что не очень популярен (поэтому при использовании как бы являешься и бета-тестером). Имел некоторые долгие баги — например, его версия, использующая libevent, стала пригодной к использованию только в 1.2.1 — вот тогда СТРИМ на него и перешёл.

Проблема балансировки нагрузки: UDP! То есть, балансировщик сессию-то создаёт, а закрыть по закрытию коннекта не может, потому что нет понятия «закрытие коннекта» — потому что UDP, а не TCP. В итоге легко забить всю память балансировщика. Соответственно лучше всего балансировать напрямую, подменяя MAC в пакетах (как в конце концов, вроде, и сделали).

Проблемы использования — это flood (решается софтом см.выше + reverse path check), cache poisoning (аналогично), недоступные авторитативные сервера (самый отстой — ничего не сделаешь! нужно кэшировать негативные результаты, что, вообще говоря, запрещено, но в новой версии unbound есть), и неправильное использование (куча запросов типа 1.0.0.127.in-addr.arpa, 1.0.168.192.in-addr.arpa; некий «wpad»; обновляторы всяких касперских зачем-то спрашивают адреса типа a.root-servers.net).

ZABBIX (нейтрально)

Полурекламный доклад, полувведение в ZABBIX, хорошо, что ZABBIX свободный, иначе могло бы попасть в раздел «Реклама». Впечатление в целом положительное.

Как и многие свободные программы, ZABBIX начался в виде хобби — создатель в то время работал в банке и ему была нужна система мониторинга. Откуда название? Да ниоткуда, ничем не объясняется выбор — просто чуваку захотелось уникальное название, которое кроме того не было бы английским словом. А сейчас заббих вырос и его используют 7 из 10 крупнейших Латвиииийских баааанкооов (гы-гы).

«Это 100 % наш код! Не используется Nagios, не используется rrd»

Плюсы Заббиха — веб-морда написана на пых-пыхе [php] («и это плюс?!» — плюс, так как вспомните что в nagios веб-морда — это cgi, написанный на C…); умеет эскалацию (упало -> пишем админам -> 10 минут ждём -> нет реакции -> пишем злому менеджеру -> 10 минут ждём -> нет реакции -> пытаемся автоматически хотя бы ребутнуть сервер); хранит всю историю по датчикам в БД; есть возможности распределённого мониторинга как через zabbix-proxy, так и «настоящего» распределённого (к примеру мониторинг филиалов). Гибкая система. Сервер (zabbix-server) решает, баг это или фича, когда что-то не так (может же быть штатная ситуация — обновление и т. п.)

Новые технологии резервного копирования (незачёт!)

Доклад запомнился мне плохо, я уже несколько засыпал, и главное уже не записал ничего. :) в целом это был некий обзор технологий резервного копирования, инкрементальных и неинкрементальных. Чего в них «нового», я не понял совершенно. :) здесь снова упоминали DRBD, iSCSI и что-то ещё.

Отсебятина:

Попутно у меня появилась идея по репликации — чтобы ускорить восстановление, можно делать «антиинкрементальный» бэкап + контрольные суммы. Имеется ввиду следующее: есть сервер, ставится драйвер, осуществляющий репликацию диска на блочном уровне в реальном времени (каждая запись блока передаётся на сервер бэкапа). На сервере бэкапа изначально лежит полный образ первого сервера, а дальше хранится не инкрементальная цепочка diff’ов (изменившихся блоков), а наоборот — когда приходит очередной diff, он накатывается на образ, а старые данные пишутся рядом, в архив. Получается, что у нас всегда есть свежая копия, а чтобы откатить на сколько-то изменений назад, нам нужно именно ОТКАТЫВАТЬ эти изменения, а не брать самую старую копию и накатывать на неё изменения последовательно до нужного момента. Плюс контрольные суммы, которые должны быть обновляемыми, то есть чтобы не нужно было заново вычислять при изменении блока, а чтобы можно было обновлять уже сохранённые.

День второй (14.04.2009, вторник)

Как обойти спам фильтр и как этому помешать (зачёт!)

Докладчик — живчик из лаборатории Касперского, Андрей Никишин. Формально он у них вроде как эксперт. Презентация у него то ли была полиморфная, предусмотренная на 2 случая — либо он успевает рассказать обе части доклада, либо нет, то ли презентация была изначально рассчитана только на первую часть доклада — о природе спама и о том, как работают спам-фильтры. Потому что, когда время истекло, он показал слайд «Как обойти спам фильтр?» и следующий «На это у нас времени нет, в следующий раз» :)

В начале показал любопытный график — количество спама в развёртке по месяцам 2008—2009 годов (кстати в целом доля спама среди всех писем ~ 80 %). Отчётливо видно, что в ноябре 2008 количество спама упало раза в 3 (а за рубежом, вроде, раз в 5). А почему? Ну да, кризис. А потому, что именно тогда прикрыли провайдера МакКоло (McColo), не реагировавшего ни на какие наезды по поводу спама, и поэтому широко использовавшегося спамерами для размещения центров управления ботнетами. Вообще-то, как однажды сказал знакомый из какого-то провайдера Никишину, «кому спам, а кому и трафик» (кому бабушка, а кому и тёща, дай-ка ещё патронов, сынок). Правда, уже в январе 2009 количество спама вернулось на прежний уровень (быстро же у них кризис прошёл, всем бы так).

Следующая мысль: Спам Стал Клёвый. Более развёрнуто: много мошенничества, в частности, SMS-мошенничества, за смски продают всё что угодно, вплоть до нефтяных месторождений (то есть акций!). Почему SMS? Потому же, почему популярен sms-маркетинг вообще: очень просто. В случае с обычным смс-маркетингом схема такая: Реклама, Смс продавцу, Процент оператору, Деньги продавцу, Товар покупателю. В случае с чёрным смс-маркетингом ещё проще: Спам, Смс мошеннику, Процент оператору, Деньги мошеннику, А вам шиш. :)

Примеры — «ваш аккаунт на mail.ru заблокирован… просьба отправить смс на короткий номер…»; почта с логотипом билайна с предложением отправить смс за 300 р. и участвовать в лотерее, где каждый второй получит возможность купить iPhone за 999 р.; «цена доступа на порносайт сегодня снижена до 6 рублей в день!» (человек смотрит и думает о! сейчас я смогу порнуху смотреть всего за 6 рублей со всеми вытекающими, а потом если прочитать на сером фоне, там написано, что оплата 300 р. за год доступа, но что с собой за год сделать можно, я не знаю…)

Ссылки зачастую отправляют в виде ссылки на SWF-файл с редиректом «куда-нибудь», размещённый по уникальному URL на хостинге типа docs.google.com — не очень-то заблокируешь по URIBL…

Итак, фильтрация. Делится на 2 вида — лингвистическая и формальная (есть и другие методы).

Лингвистические методы делятся на количественные (дофига каких-то спамерских речевых оборотов) и качественные (тут явно про виагру с циалисом, отсекаем). Это эвристики, сигнатуры/термины (хеши, вычисляемые по тексту), шинглы (штука, используемая поисковиками для определения плагиата). Недостаток — требуется довольно длинный текст для корректной работы, так как есть всякие граничные слова типа «СОСАТЬ!». Ещё есть картинки, тут можно пользоваться статистическими методами, OCR или графическими сигнатурами (тоже типа хешей).

Формальные методы, или правила — здесь всё что угодно. Фильтрация по заголовкам, по регэкспам в теле, всевозможные чёрные списки — RBL (Realtime Blackhole List), URIBL (URI BlackList), whitelisting, graylisting (докладчик его, кстати, не любит); хороший пример — в одной гос.организации сразу отсекают все письма, у которых X-Mailer = The Bat!, так как ни у них, ни у их корреспондентов его нет и быть не может, и это известно. Недостаток — чтобы писать сложные правила, нужен большой опыт и большой выпуклый глаз. Например, спам-модуль вируса Conficker (он же Kido) — Xmas/Validag — довольно умный, письма посылает всегда разные, с разными заголовками и т. п. Однако, чувак сказал что в принципе посмотрев на заголовки письма своим «выпуклым глазом», по Message-ID он всегда может сказать, Validag ли это, но как — точно пока не знает. Чтобы написать правило, нужно время.

Организация небольшого почтового сервера (нейтрально)

О! Снова Дремучий Лес и Фил Кулин / Кул Филин :) экстраординарного мало, все идеи довольно стандартные, ну сервер, ну и сервер. Ну почтовый. Ну работает. Ну, все молодцы. :) самое полезное — перечислил некоторые стандартные проблемы хостинга с почтой.

Меня, говорит, почта моя совсем не волновала)) работал себе и работал (в хостинге), пока совсем не легла. Тогда мы реально сели с коллегами в кабинете, заперлись и т.п… <ну хоть ели-пили, в туалет-то ходили? — прим.вред>. Частая фраза про почту, говорит — работает, но как работает, не знаю.

Собственно, а что от почты хочет пользователь? Чтобы доставлялось быстро, чтобы не было спама, но вся нужная почта была на месте, чтобы была либо гарантия доставки, либо письмо о НЕдоставке. А что от почты хочет админ? Чтобы было гибко, масштабируемо, обновляемо, стабильно, мало нагрузки, отказоустойчиво, и максимально соответствовало стандартам <требовательный какой-то админ попался — прим.вред>. Показал картинку, чтобы обычно представляет почтовый сервер — куча всяких связей, элементов. Дальше сказал, что ему какая-то девушка подарила «ловца снов» (тоже много каких-то ниточек-хрениточек, такой типа талисман) и что он выглядит куда приятнее, и что давайте приведём сервер к такому же виду)) и что ловец снов сейчас висит у него над кроватью — тут кто-то спросил — и как, работает? Он такой — типа)), ну да, работает. — Не падает? — Нет, как ни странно за всё время ни разу не упал))) просто висит! — ПРОСТО ВИСИТ?! <аплодисменты>.

Основные проблемы хостинга — частично всё тот же спам, вирусы (источник вирусов — это, как правило, почта с авторизацией), частично кривые программы пользователей, но тут только ловить и по шапке давать. Плюс вводить правила фильтрации почты от программ — чтобы, по меньшей мере, были Message-ID, From, Received. Причём количество Received можно отслеживать, обычно он должен быть только 1, максимум 2 (например для SquirrelMail). Из юмора — в HELO от клиентских машин, обычно виндовых, может быть всё что угодно — всякая «катямаша», причём на русском, ибо виндовые клиенты, как стандартные так и нестандартные, обычно подставляют туда имя компьютера.

Ещё из заметок — лично у него сделан каскад очередей, типа сначала попало в первую, если не ушло за 15 минут — во вторую, если не ушло за день — в третью, если не ушло за неделю — … ну что же, не судьба.

Выдержит или упадёт? (нейтрально)

Докладывал чувак с фамилией «Йа Копейко», про то, как они с Олегом Буниным оценивали нагрузочную способность будущего «амбизиозного проекта» — очередного сайта знакомств… А именно, сайта незнакомка.ру. Исходная задача — всё как всегда, стандартный Выб2.0: 2 CARP’а, 2 фронтенда, 2 бэкенда приложения (Apache + mod_perl), 2 бэкенда картинок (генерации и т.п). База — PostgreSQL. Кэш — memcached. Расчётные данные — сколько-то там дохрена пользователей, хитов и т. п.; объём html страницы — 300 Кб <O_o жесть — прим.вред>; много картинок (в основном превьюшек). Вопросы — выдержит или нет? И когда упадёт?

В общем, идея такая: сначала он дополнительно уточнил исходные условия, выяснив распределение нагрузки на мамбу.ру (по данным счётчиков), таким образом выяснив пиковую нагрузку запросов в секунду, выяснил примерное распределение пользователей по скоростям канала (получил почему-то равные примерно количества 45 кб/с / 128 кб/с / >=512 кб/с), таким образом получив примерное количество одновременных соединений в секунду (учитывая размер контента). Посмотрел и решил что nginx это выдержит без проблем (аэрофлотnginx такой — он всё выдержит).

Дальше принял какие-то райские условия, когда детёныш апача с мод_перлом весит 25 Мб <не знаю, где он таких нашёл — обычно 40-50 и больше>, детёныш постгреса тоже где-то 25 Мб. Принял, что сервера все настроены здоровски, ни в какие ужасы не упираются. Видео не учитывается (да его решили в начале и не делать). После чего решил, что в память и в скорость генерации страниц они тоже не упираются (пусть 1 страница генерится 0.1 сек — при кэшировании …), таким образом, сведя задачу к задаче расчёта пиковой производительности сети. Рай, да, я понимаю. :) дальше уже оценить легко — оцениваем соотношение страниц и картинок, получаем 616 Мбит/с на фронтенд. Решаем, что плоховато ему будет, хотя обсчитать он это сможет. + порекомендовал добавить ещё один бэкенд, хотя и два выдержало бы.

Всё.

Практическое применение системы виртуализации Xen (незачёт!)

Скучный доклад — введение в XEN + «зачем он нужен» с точки зрения докладчика — это ровно затем, чтобы сэкономить на железках. Во-первых про XEN уже все всё знают, во-вторых это было совсем-совсем начальное введение, в-третьих, уж если рассказывать введение в XEN, то начинать надо с того факта, что делать его начали во времена, когда не было ещё никаких Vanderpool (Intel) и Pacifica (AMD) (это аппаратные возможности виртуализации ЦП), а вмварь (VMWare) давала неслабые накладные расходы несмотря на то, что уже научилась эмулировать не обязательно все, а только привилегированные инструкции. И что стояла перед ними задача — сделать честную виртуализацию (несколько независимых ОС одновременно) почти без накладных расходов по производительности. И что выбрали они для этого путь под названием «паравиртуализация», когда в 0-е кольцо защиты попадает гипервизор (сам XEN), а операционки работают в 1-ом кольце защиты (а приложения в 3-ем). И что для этого модифицировали ядро Linux, и научились-таки это делать, а потом уже и интел с амд подтянулись вслед за ними, и появилась возможность параллельно Linux и винду тоже запускать. К этому времени, правда, уже и во FreeBSD почти добавили паравиртуализацию (сейчас добавлена окончательно).

Управление ресурсами в Linux и OpenVZ (зачёт!)

Parallels / бывший SWSoft — контора хорошая, там m0r1k работал (и как-то раз «выход из окна 7-ого этажа с использованием спортивных принадлежностей» совершил). Да и вообще там умных людей много работает. Главный их успех, на мой взгляд — это, конечно, Virtuozzo, и его открытая всем ветрам часть — OpenVZ. То есть, как я уже писал выше, самая популярная технология на платных хостингах, с помощью которой предоставляют виртуальные выделенные сервера, или реализация контейнеров под Linux.

Плюсы подхода «одно ядро, много копий окружения» понятны — это и высокая плотность размещения «тазиков» на реальной железке, и лёгкое динамическое управление ресурсами, это и практически нулевые накладные расходы на виртуализацию… Это какбэ деление большого зала на комнаты. Удобно. Аналоги OpenVZ в этом плане — FreeBSD jails, Linux jails (RSBAC), Linux VServer, Solaris zones, IBM AIX6 Workload Partitions. Есть статья и про OpenVZ vs Xen — итог очевиден, накладные расходы Xen больше — запустили 4 копии какого-то интернет-магазина и по нагрузке уже упёрлись, а OpenVZ запустили 6 тех же копий и всё равно ещё шевелилось.

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

А чем управлять? В целом — процессор, память (юзерспейс, ядро, page cache), диск (место, i/o rate, объём mmap), сеть. Вот по поводу сети уже всё сделано «за нас» — есть хорошая утилита tc (от «traffic shaping») — и она умеет всё что душе угодно. Написана, кстати, нашим соотечественником :)

Что уже есть по поводу ограничений:

• CPU: nice/renice (приоритет), отдельный приоритет реального времени, ещё есть опция ulimit -c с лозунгом «если враг не сдаётся, его перезагружают» (то есть если процесс съедает суммарно больше чем n секунд CPU — его убивают).
• Диск: UNIX квоты очень хороши, а приложения вполне готовы к отказам, мистических ошибок быть не должно.
• Остальное: ulimit. Где-то 25 параметров. Но с ним куча проблем — детализация мала, текущее использование ресурсов нельзя посмотреть, нельзя посмотреть когда был «в опасной близости» — видно только когда убьют. На юлимиты памяти ядро в большинстве случаев кладёт с прибором. И самое главное — юлимиты нельзя менять на ходу!

Посему виртуозники придумали свой механизм (патч ядра) — user_beancounter’ы. У них всех вышеперечисленных недостатков нет. Они даже дают защиту от некоторых стандартных эксплойтов типа:

• while(1) { mkdir(«dir»); chdir(«dir»); } — что оно съест? Иноды, место на диске? Ни то, ни другое! Оно очень быстро съест структуру данных под названием «dcache», которая предназначена для быстрых прогулок по иерархиям каталогов. dcache — это память ядра, поэтому сам такой эксплойт не использует памяти вообще, памяти начинает быстро не хватать, ядро начинает сналача яростно свопиться, потом, когда свопить уже нечего и памяти «нет совсем-совсем», запускается OutOfMemoryKiller и начинает убивать процессы, использующие больше всех памяти — то есть любые процессы (X сервер и т. п.), но только не этот эксплойт. Стандартный Linux дохнет весьма быстро. А вот с OpenVZ-патчами такое не пройдёт.
• mmap(4096, PROT_READ); mmap(4096, PROT_WRITE); …; while(1) fork(); — то есть много чередующихся mmap с разным доступом, чтобы они не могли срастись, а потом бесконечный fork(). В количество процессов система не упрётся — не успеет. Гораздо раньше этот эксплойт съест vmarea, которая также является памятью ядра, и ситуация будет аналогичная предыдущей. От этого тоже есть защита.

Ну и понятно, что все эти мысли в голове не только у виртуозников, поэтому сейчас в ядре появляется механизм контрол-групп (CGroups), то есть групп процессов с подключаемыми ограничениями и простым интерфейсом, управляемым через виртуальную ФС. + Kernel memory controller, который тоже теперь будет в курсе сигрупп, то есть будет их учитывать при cache reclamation (освобождение памяти из-под кэша) и out of memory killer; и тоже будет управляться через ФС. В ванилле его пока нет, это ветка ядра '-mm'.

Ну и рассказал про их список TODO — это поддержка сигрупп и kernel memory controller — учёт длин маппингов, честный учёт разделяемых страниц памяти, чекпоинтинг, IO контроллер, и прочие ништяки OpenVZ — всё портировать в нормальное ядро.

PostgreSQL 8.4: что в новой версии (слушал конец)

Запомнился один вопрос:

• Здравствуйте, у меня вопрос, я вот всегда слышал, что у постгреса проблемы с тем, чтобы сделать SELECT COUNT(*) из таблицы, сейчас что-то поменялось?
• Постгресмен отвечает: Ну, типа да, ну если у вас давно не делался вакуум, плохие настройки FSM, и т. п. то да, будет много мусора, будет подтормаживать.
• И тут встаёт MySQL’щик и говорит: Давайте я лучше отвечу. Вообще этот вопрос я уже очень много раз слышал, его много обсуждают, тут всё дело вот в чём: мы [mysql] храним COUNT(*) в метаданных таблицы, подход немножко ламерский, но работает (то есть в MySQL тоже есть движки, которые этого не делают, но MyISAM и InnoDB это делают), и запросы COUNT(*) проходят мгновенно, и из-за этого есть такой миф, что MySQL — это самая быстрая база данных, так вот, вы поймите, что это не так, и не надо вот сейчас гнобить постгрес за это, другие базы данных тоже этого не делают.

А вообще сделаю копипаст с ЛОР’а, потому что слушал только самый конец, а сегодня как раз вышла первая 8.4-beta.

• «оконные» функции (Windowing Functions)
• общие табличные выражения (Common Table Expression) и рекурсивные запросы
• функции с переменным числом аргументов (Variadic) и значения по умолчанию для параметров функций
• возможность восстановления дампа в несколько одновременных потоков
• привилегии на столбцы таблиц
• собственные параметры локали для каждой БД
• улучшенная производительность для запросов с EXISTS и NOT EXISTS
• «многоколоночные» GIN-индексы
• префиксный поиск с использованием GIN-индексов
• улучшенные hash-индексы
• более простой в использовании сервер «тёплого резерва» (Warm Standby)
• автоматическая настройка «карт свободного пространства» (Free Space Map)
• «карты видимости» (Visibility Maps), улучшающие производительность вакуум-процессов
• терминал psql подстраивается под версию сервера, с которым работает
• поддержка SSL-сертификатов для аутентификации пользователей
• статистика по использованию функций в режиме реального времени
• упрощённое редактирование функций в терминале psql
• новые contrib-модули: pg_stat_statements, auto_explain (автоматически пишет в slow log планы запросов), citext, btree_gin

Стык MySQL и администрирования (нейтрально)

Парень из MySQL, тот же самый Костя Осипов, рассказывал не то что про заявленный стык, а про некоторый набор полезных Perl скриптов для администрирования MySQL, автор которых азм есть Барон Шварц. Скрипты дают довольно приятные возможности:

• проверка контрольных сумм таблиц на мастере/слейвах и синхронизация «если что»
• обеспеч. задержки репликации на слейве в несколько минут (чтобы если «всё грохнешь», было 5 минут восстановиться — это не замена бэкапу, в основном потому, что бэкап можно положить в шкаф!)
• анализ slow log и автоматический анализ запросов (explain)
• архивация, dump, restore, аудит и т. п.

Везде есть опция --dry-run (то есть ничего не делать, а показать, что собираемся делать).

Примерно так.

Citrix XenApp — виртуализация приложений (реклама, незачёт!)

Много вумных слов про «доставку приложений» — от этого словосочетания меня лично просто тошнит. :)

Просто реклама XenApp, какое оно хорошее, как админ может нажать сюда-туда, и ещё куда-нибудь, сделать то и это.

Практически не слушал, и слава богу.

Сравнение почтовых систем со встроенными средствами коллективной работы (нейтрально)

Докладывался парень неплохо, тема средней интересности, рассматриваются как FOSS продукты, так и платные. У офисного планктона тема наводит на мысли в первую очередь, конечно, о M$ Exchange.

Во-первых, что такое коллективная работа? Это: обмен сообщениями, передача документов, организация мероприятий, контроль и раздача задач, напоминания / записки, замещение коллег (частичная или полная передача прав на что-то). Ну, и вот мы решаем, что делать это электронно — хорошо, удобно и быстро, и начинаем искать средства.

Буржуи: Axigen, CommuniGate, Kerio, Groupwise, Exchange. Сортировка в направлении роста цены. Axigen самый дешёвый, при этом полнофункциональный и кроссплатформенный (стоит где-то 1200$ на 100 пользователей, кажется), CommuniGate и Kerio ~ в 2 раза дороже Axigen, Groupwise ~ в 3 раза дороже Axigen, и Exchange завершает список, так как стоит в районе 8000$ <афигеть, и ведь платят за этот отстой, лучше бы мне дали, я бы себе импрезу купил :D — прим.вред>.

Axigen начинался на FreeBSD, потом переполз на остальные ОС, в том числе винды и солярку, в том числе есть коннектор для аутглюка. Расхожее мнение, что коннектор глючнее самого аутглюка, однако докладчик сказал, что когда они тестировали и обнаружили проблемы с русской кодировкой, написали разработчикам и те сразу пофиксили и прислали новую бету.

Теперь решаем, что всё это было Ugly and Stupid (c) Torvalds, и задаёмся поиском FOSS продуктов. Это: Egroupware (полный функционал, есть Project Management), Horde (известны инсталляции > 1.5 млн ящиков), More.Groupware (слабоват), OpenGroupware (полный функционал, есть загрузочный CD), Zimbra (весьма хороша, известны инсталляции > 650 тыс. ящиков). Что любопытно, размер известных инсталляций FOSS сильно больше, чем аналогичный у коммерческих.

Итог сравнения — первое место за Axigen, второе за Zimbra. Эксчендж глубоко в…, где ему и место.

Сетевая виртуальная лаборатория (нейтрально)

Один из неудачно послушанных докладов — засыпал на ходу :) хотя доклад был неплохой, докладчик был автор xgu.ru, и рассказывал про утилиту (вернее сказать, «что написал утилиту»), которая на основе «библиотечных» стандартных образов систем, взятых с Amazon S3 (или как оно у них называется), на основе эмулятора MIPS dynamips для эмуляции Cisco, XEN для создания виртуальных машин x86, и простенького конфигурационного файла позволяет разворачивать готовые конфигурации из N виртуальных машин с различными конфигурациями сети (виртуальными роутерами, свичами). БольшУю часть времени доклада заняла демонстрация, где он показывал, что это работает. Подтверждаю, это работает :) как — он ни рассказывал, ни показывал.

Для тестирования, по-видимому, вещь очень классная, почти незаменимая. Можно взять на заметку.

Виртуализация сетевых подключений (реклама, незачёт!)

И реклама, и незачёт. Была мысль, что надо кастовать Стаса с презентацией «как делать презентации», так как докладчик этого, видимо, делать не умел совсем.

Рассказывал про HP’шные блейды, и в основном про то, что если между блейдами и cisками поставить несколько неуправляемых свичей, проводов станет меньше. Ещё пытался заикнуться, что система управления чем-то там сделает чего-то там легко при переключении чего-то одного на чего-то другое, но никто в это не поверил, задали вопрос, докладчик сказал ну да, придётся всё равно немного допиливать. А это ещё и продают. :-x

Использование IP сетей в современных SAN: iSCSI, FCIP, iFCP (незачёт!)

Хранилища бывают DAS (Direct Attached Storage, подключённые напрямую харды вплоть до флешек), NAS (Network Attached Storage, подключённые по сети системы хранения, единица передачи — файл) и SAN (Storage Area Network, имеются ввиду всякие Fibre Channel и iSCSI). Речь про последние. Несмотря на заявленные iSCSI, FCIP, iFCP рассказ был только про iSCSI, и представлял собой по сути некое введение в то, а что же такое есть iSCSI. В двух словах понятно, это инкапсуляция SCSI-команд для передачи по сети, с огромными, кстати, накладными расходами. Вообще доклад был грустен и снова навевал желание сделать summon Стаса. Докладчик iSCSI хвалил и радовался, что можно физически далеко разносить сервера, делать всякую репликацию, и что если сеть сделать 10GbE вместо обычно существующих 1GbE, это классное пространство для ускорения! (классное-то классное, да только 1 раз классное, 100GbE никто пока не придумал)

Кластерные системы хранения. Решение SoFS (реклама, незачёт!)

Сначала слышал ключевые слова «open-source», а потом оказалось, что этот IBM SoFS лицензируется аж по количеству пользователей (поправьте если вру). Испытал O_o, решил, что они уроды и «ugly and stupid» (c) Linus Torvalds, слушать перестал. Тем не менее, это уже был конец доклада и всё уже было рассказано.

Идея у них такая — взять кластер, на нём развернуть GPFS (кластерная ФС от IBM), запатчить Samba чтобы не было проблем с одновременным доступом из разных мест, и сделать CIFS-экспорт всего этого кластера хранения. Добавить HTTP и FTP по вкусу, получить такую вполне себе NAS-систему. Молодцы, справились. :) патчи для самбы были отправлены сообществу — и это «+».

Система хранения данных из того, что было под рукой (зачёт!)

Очень интересный и познавательный доклад бегуна (чувака из Begun’а) про «я тебя слепила из того, что было» — про то, как они из обычного сервера, ciськи, Linux’а и протокола AoE сделали сетевую систему хранения, дающую пиковую скорость записи ~350 Мбайт/сек, и чтения ~380 Мбайт/сек без кэширования.

Что такое AoE? AoE означает «ATA over Ethernet» — протокол инкапсуляции обычных ATA-команд в Ethernet-фреймы. Протокол Очень Простой, всё описание занимает страницы 2 (в противовес ~100 iSCSI, правда сравнивать его скорее надо с Fibre Channel over Ethernet, а не с iSCSI), а накладные расходы минимальны как по производительности, так и по объёму передаваемых данных. Всё это потому, что инкапсуляция ведётся именно в Ethernet-фреймы, а не в IP-пакеты, то есть протокол работает на сетевом уровне. Хотя это имеет и недостаток — AoE не пустишь через Интернет (без дополнительной инкапсуляции). Из других плюсов протокола — работает с любым UNIX устройством, фактически с любым файлом, очень нетребователен к ресурсам, поддерживается на многих ОС — в Linux, OpenBSD и Plan9 встроен, а по меньшей мере для Windows и FreeBSD есть драйверы.

Простоту AoE легко оценить даже по командной строке модуля ядра Linux «aoe» (это и есть модуль-клиент AoE) — там есть всего 2 параметра: aoe_iflist (список сетевых интерфейсов, на которых нужно работать), и aoe_deadsecs (таймаут команд). Соответствующие устройства после подключения появятся в /dev/etherd/eX.XpX (X — числа). Серверов AoE есть несколько, но наименее кривой — это vblade, на нём и тестировали.

Собственно, предыстория этой системы хранения такова: понадобилась система хранения. :) в какой-то момент стали смотреть на штуку под названием Coraid EtherDrive, и оказалось, что это обычная серверная железка с какой-то «хитрой ОС» внутри (на форумах прочитали, что это зайчег (Plan9)), с обычной сетевой карточкой… И с AoE. После чего, конечно, решили — а зачем нам это покупать?!! Мы лучше сами соберём: сервер с рэйд-контроллером на 16 хардов есть, циска есть, AoE тоже есть.

• Сначала попробовали на совсем тестовой конфигурации, без рэйда на офисном железе. Результат — 90 Мбайт/сек (гигабитная сеть). Весьма неплохо, решили продолжать.
• Потом собрали конфигурацию с 2’мя 5-ыми RAID’ами по 8 хардов, по одному проводу (cisco portchannel, как и везде дальше). Результат — 25 % занятость канала, 50-70 Мбайт/сек скорость. Как-то грустно — решили тюнить дальше.
• Сделали 4 stripe (RAID 0) по 4 харда, пустили их по 4 проводам. Итог — 60 % канала, 100—120 Мбайт/сек. Уже лучше.
• Обновили все драйвера и сервер — сразу получили 80 % канала и 350 Мбайт/сек.
• Решили попробовать потюнить ещё: включили jumbo frame’ы, сделали MTU, краткое размеру блока ФС, блоку LVM и блоку рэйд-контроллера. Итог — 350 Мбайт/сек запись и 380 Мбайт/сек чтение. Если сюда добавить ещё кэш (на тестах он был везде отключён, либо файлы были большие и пролетали мимо него) — 900 Мбайт/сек в пике где-то получится вполне.

По надёжности: по истечению таймаута страшного ничего не происходит, AoE отваливается, но вполне нормально отмонтируется и ничего не вешает. И чинится «если что» легко, так как все системы и комплектующие дешёвые и стандартные. В общем, «супер».

Плюс было у автора ещё несколько хитрых идей:

• можно сделать сборочный tmpfs (RAMдиск), опубликованный по сети;
• можно сделать «общий диск» (правда, 1 писатель и много читателей);
• можно сделать географически распределённое зеркало.

Программа конференции

http://www.rootconf.ru/themes/13249.html

Легенда

• Операционные системы
• Хранение данных
• Менеджмент
• Смежные технологии
• Сети
• ЦОД, Дата-центры
• Аппаратное обеспечение
• Виртуализация
• Сервера
• Офис
• Программное обеспечение

13 апреля

14 апреля