В MySQL есть очень полезная функциональность — кеш запросов. Кеш запросов доступен в MySQL начиная с версии 4.0.
Многие СУБД имеют подобную функциональность, но в отличие от MySQL они кешируют планы выполнения запросов, тогда как MySQL кеширует результаты запросов.
Дальше о том, как работает кеш запросов, как его настраивать и оптимально использовать.

Спойлер: Open vSwitch версий меньше 1.11 уязвим перед атакой вида «flow flood», позволяющей злоумышленнику прервать работу сети отправкой относительно небольшого потока пакетов в адрес любой виртуальной машины. Версии 1.11 и старше проблеме не подвержены. Большинство серверов с OVS до сих пор используют OVS 1.4 или 1.9 (LTS-версии). Администраторам таких систем настоятельно рекомендуется обновить систему на более новую версию OVS.

Лирика: Прошло уже больше полутора лет с момента, когда я впервые сумел воспроизвести эту проблему. В рассылке OVS на жалобу сказали, что «в следующих версиях исправят» — и исправили, пол-года спустя. Однако, это исправление не коснулось LTS-версии, а значит, большинство систем, использующих OVS, всё так же уязвимо. Я пытался несколько раз связаться с Citrix'ом (т.к. он использует самую уязвимую версию OVS в составе Xen Server — в тот момент это был мой основной продукт для эксплуатации), но никакой внятной реакции не последовало. Сейчас у администраторов есть возможность устранить проблему малой кровью, так что я решил опубликовать описание очень простой в воспроизведении и крайне запутанной и в диагностике проблемы — проблеме «flow congestion», она же «flow flood attack», она же «странная неведомая фигня, из-за которой всё работает странно». Раньше в комментариях и в рассылках про эту проблему я уже несколько раз писал, но у меня ни разу не хватало пороху полностью описать проблему на русском языке так, чтобы суть проблемы была понятна обычному айтишнику. Исправляюсь.

Следующая строчка hping3 -i u10 virtual.machine.i.p нарушает работоспособность хоста виртуализации, где запущена виртуальная машина. И не только хоста виртуализации — любую систему, работающую на Open vSwitch версий меньше 1.11. Я делаю особый упор на версиях 1.4.3 и 1.9, потому что они являются LTS-версиями и используются чаще всего.

Более суровая версия того же вызова, на этот раз с нарушением правил пользования сетью: hping3 --flood --rand-source virtual.machine.i.p. Соотношение исходящего трафика (~10-60Мбит/с) и (потенциальной) пропускной способности интерфейса жертвы (2x10G, соотношение по доступной полосе атакующий/атакуемый порядка 1:300-1:1000) позволяет говорить именно про уязвимость, а не про традиционную DoS атаку флудом, забивающем каналы аплинков до нерабочего состояния.

Симптомы со стороны хоста виртуализации: неожиданные задержки при открытии соединений, рост потребления CPU процессом ovs-vswitchd до 100%, потеря пакетов для новых или малоактивных сессий. Если используется OVS 1.4, то процесс ovs-vswitchd не только съедает свои 100% CPU, но и начинает подъедать память и делает это со скоростью до 20 мегабайт в минуту, пока к нему не приходит добрый дедушка OOM и не проводит воспитательную беседу.

Puppet — довольно удобный инструмент для управления конфигурациями. По сути, это система, которая позволяет автоматизировать настройку и управление большим парком машин и сервисов.

Базовой информации о самой системе много, в том числе и на Хабре: здесь, здесь и здесь. Мы же постарались собрать в одной статье несколько «рецептов» использования Puppet под действительно большими нагрузками — в «боевых условиях» Badoo.

О чём пойдет речь:

• Puppet: ликбез;
• кластеризация, масштабирование;
• асинхронный Storeconfigs;
• сбор отчётов;
• анализ полученных данных.

IPv6 уверенно шагает рано или поздно войдёт в нашу жизнь в той же степени, что и IPv4. Интересная особенность — долгий период разработки и внедрения привёл к тому, что некоторые первоначальные идеи были списаны в утиль, а сама конструкция постепенно обросла костылями. И, что обидно, к решению некоторых серьёзных проблем приступили только недавно.

Под катом — как положить IPv6 и даже IPv4 сеть DoS-атакой NDP Table Exhaustion, а также варианты полумер и мер защиты.

Всем доброго времени суток!

Как видно из заголовка, речь пойдет о двух программах:
1. Open Computers and Software Inventory
OCS-Inventory основан на распределяемых модулях, устанавливаемых на инвентаризируемые машины, которые отсылают подробную информацию о системе, подключенных устройствах и установленном ПО в выделенную базу данных.
Поддерживаются следующие OS: Microsoft Windows, Linux, *BSD, Sun Solaris, IBM AIX, HP-UX, MacOS X

2. GPLI — Guestion Libre de Parc Informatique
Проект предназначен для работы с базой данных IT и телекоммуникационного оборудования, установленного на предприятии. Также имеется возможность ведения учета расходных материалов и организации службы технической поддержки по расписанию и по заявкам пользователей.

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

Более года назад я написал длинную и скучную статью про стремительное изменение рабочей среды, про глобализацию, мобильность и безопасность различных типов удаленного доступа. Из-за отсутствия картинок и сухого слога статья не вызвала оживленной дискуссии, но лично мне дала сильный импульс в нужном направлении. Мысли об удобной и безопасной реализации удаленного доступа для сотрудников к ресурсам корпоративной сети воплотились в реальном продукте с кодовым названием «VPN Box».

Хочу рассказать, что получилось через год исследований и разработок. Все работы велись мною в норвежской компании INFOSS AS (не реклама), поэтому их логотип стоит на конечном устройстве.

С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

Во многих западных странах IT-аутсорсинг регулируется либо отраслевыми стандартами, либо вообще на госуровне. У нас такого нет. Поэтому за несколько лет был собран документ, который детально определяет термины в IT-аутсорсинге и расписывает, что в какой тип работ конкретно входит. С его помощью мы документируем работы, а потом чётко и прозрачно считаем, что сколько стоит.

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

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

Две рефлектограммы одной и той же трассы на разных длинах волн, открытые в программе-viewer'е

Здравствуйте, хабражители! В этой, четвёртой по счёту, статье про работу с оптикой, я расскажу про то, как снять рефлектограмму трассы оптическим рефлектометром и как понять, что мы на ней видим. Также коснёмся вопросов измерений тестерами, настройки рефлектометра и некоторых других.
Новая часть не выходила так долго, потому что я писал диплом, плюс были вопросы по работе. Но теперь диплом защищён, лень побеждена и руки дошли, чтобы дописать статью.

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

Часть 1 здесь
Часть 2 здесь
Часть 3 здесь

Осторожно: много картинок, трафик!

Что может узнать атакующий

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

Уязвимость двусторонняя: если уязвимый клиент подключается к серверу злоумышленника, то злоумышленник может читать память процесса клиента. Пример уязвимых клиентов: MariaDB, wget, curl, git, nginx (в режиме прокси).

Несколько дней назад Роберт Грэм начал работу над серией статей C10M и планирует закончить работу в июле этого года.

Сегодня уже доступны следующие главы:

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.

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

Часть первая

Продолжаем

Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.

В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:

# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.

После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:

# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2

Pacemaker

Итак, менеджер кластера.

Часть вторая

Прелюдия

Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.

Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам.

Вводные

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

В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.

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

В качестве софта было выбрано:

• Debian Wheezy + LTS ядро 3.10
• iSCSI-таргет SCST
• DRBD для репликации
• Pacemaker для управления ресурсами кластера и мониторинга
• Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)

В итоге, в недолгих муках была рождена такая несложная схема:

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

ISCSI

Перед тем, как рассказать про ISCSI — несколько слов о разных типах удалённого доступа к информации в современных сетях.

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

Здравствуйте.

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

Что необходимо?

Для загрузки системы нужны три компонента: ядро, initramfs и корневая файловая система.
Ядро и initramfs мы передадим по TFTP, а корневую файловую систему — по iSCSI.

iSCSI-таргеты

Для Ubuntu возможно использовать различные iSCSI-таргеты. Вот неполный их список:

• ISCSI Enterprise Target — одна из самых старых реализаций iSCSI-таргета на Linux. Насколько мне известно, жива и здравствует, однако требует установки (в Ubuntu) через DKMS и совсем лёгкого дребезга бубнов. На opennet.ru есть рабочий HOWTO, применимый и к более поздним версиям ОС (Precise)
• SCSI Target Framework (STGT/TGT) — реализация iSCSI-таргета, портированная из BSD-систем. В отличии от IET, позволяет использовать не только iSCSI, но и другие родственные технологии (такие, как, например, SRP). К сожалению, код STGT в части iSCSI в линуксе работает в userspace. Как следствие, производительность получается где-то в районе плинтуса.
• SCST — новая реализация универсального таргета для Linux. По заявлениям разработчиков обладает массой преимуществ и фишек. В ядро не включена, для установки требует патчей исходников ядра и продолжительного зубодробительного секса. По слухам, мила, прекрасна и похожа на сакуру. Когда-то давно ее использовали, например, в Оверсан-Скалакси (их опыт вкратце описан на хабре). Пакеты для Ubuntu перестали поддерживаться около полутора лет назад, в SVN есть некоторая активность, то есть проект жив и здравствует. Кстати, разработчики — русские парни :)
• LIO — Linux Unified Target, универсальная система, реализующая iSCSI, SRP, FCoE и несколько других вариантов экспорта устройств в сеть. Официально включена в ядро и является стандартным таргетом, начиная с версии 2.6.38. К ней есть определенные претензии в плане того, что на официальном сайте активно продвигается проприетарная сборка, обладающая большим функционалом, но оставим вопли RMS.

Статья написана по материалам моего доклада на CodeCamp 2009.

Для многих из нас настает тот долгожданный день, когда аудитория сайта начинает стремительно расти. Каждое утро мы, затая дыхание, смотрим на графики google analitycs и расплываемся в улыбке, когда взят рубеж в очередную тысячу посетителей в день. Как правило, рост посещаемости не совпадает с ростом технической базы и сайт начинает тормозить. Тут в игру вступает сисадмин...

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

Wake-on-LAN (WOL; в переводе с англ. — «пробуждение по [сигналу из] локальной сети») — технология, позволяющая удалённо включить компьютер посредством отправки через локальную сеть специальной последовательности байтов. wiki

И все бы хорошо, если бы не одно но. После сбоя питания ваш компьютер не включится.
Согласитесь, это будет «приятной» неожиданностью, особенно если вы находитесь за пару тысяч километров от него.
Одно из решений написано здесь, но оно аппаратно-программное, а ведь можно обойтись без дополнительного железа.