книги хакеры / журнал хакер / 187_Optimized

Роман Ярыженко rommanio@yandex.ru

Реинкарнация Красной Шапочки

ŦśŞţŠŖŦţŖŬŞŵ

ŠŦŖŧţŤş

ŮŖťŤŭŠŞ

ОБЗОР

ДИСТРИБУТИВА

RHEL 7

Относительно недавно вышел релиз дистрибутива, по праву считающегося первым в корпоративном сек-

торе, — Red Hat Enterprise Linux 7.

Не дожидаясь появления его клонов, мы решили посмотреть, что же нового предоставляет нам этот титан

вмире Open Source, совместивший

всвое время, казалось бы, несовместимое — зарабатывание денег и открытую модель.

ВВЕДЕНИЕ

Red Hat выпускает мажорные версии своих дистрибутивов раз в три-четыре года — вечность в современном мире ИТ. И 10 июня вышла седьмая версия флагманского продукта компании — RHEL. Прежде всего следует дать краткий обзор, что новое появилось в данном дистрибутиве:

•Ядро 3.10, в котором, в частности, появился уровень кеширования Bcache, позволяющий использовать SSD-диски в качестве кеша для HDD, а также поддержка технологии zSwap для сжатия неиспользуемых страниц прямо в памяти, без сбрасывания на диск.

•В качестве файловой системы используется XFS. Btrfs, видимо, посчитали слишком сырой для корпоративного сектора, хотя она и есть в списке доступных ФС.

•Systemd заменил-таки старую добрую инициализацию SysV.

•В качестве графической оболочки используется GNOME 3, правда, в отличие от некоторых других, Red Hat включил интерфейс Classic Shell для безболезненного перехода со старых версий.

•Samba 4, позволяющая создать контроллер домена Active Directory.

•Платформа x86 более не поддерживается, только x64.

Можно перечислить еще много всего, но данная статья все же не является перепечатанными Release Notes, посему на этом и остановимся и перейдем к самому обзору.

Unixoid

Установка. Обзор

УСТАНОВКА

Red Hat верен себе — Live-версии дистрибутивов не поставляются, поэтому знакомство с ним придется начать по старинке — с установки. Установить можно как с DVD, так и с флешки (для последнего на не-UEFI-системах достаточно скопировать образ DVD на флешку с помощью dd).

Red Hat предоставляет три образа дистрибутива, на этапе установки отличающихся лишь набором пакетов: Server, Workstation и Client. На практике же набор пакетов в Workstation

такой же, как и в Client, даже больше, и, таким образом, последний рассматривать не имеет смысла.

После загрузки с носителя и необязательной проверки целостности запустится стандартный установщик RHEL — Anaconda, который тут же попросит задать язык. Следом за выбором языка появится экран обзора установки, где можно настроить сеть, часовой пояс и разбиение и выбрать пакеты. Этим установщик отличается от предыдущих версий, где данные параметры выбирались на нескольких последовательных экранах.

В списке часовых поясов присутствует в том числе и мой город, который во многих других продуктах (даже проприетарных) отсутствует.

Сетевой адаптер по умолчанию выключен, даже если он присутствует в единственном экземпляре. Решение достаточно спорное — например, в том же диалоге выбора часового пояса, который на обзорном экране идет первым, присутствует переключатель для NTP, без сети попросту не работающий.

Выбор пакетов сводится к выбору категорий, что, в общемто, логично. Немного смутило то, что при переключении основных опций дополнительные не сохраняются, — по-видимому, предполагается, что пользователь четко знает, чего хочет. Также был замечен немного неправильный перевод: «Резервный клиент» стоит переводить как «Клиент для резервного копирования». Кроме того, из названий дополнений в большинстве случаев не совсем очевидно, какое ПО им соответствует. Так, можно лишь предполагать, что под «Офисным комплектом» подразумевается LibreOffice. А что подразумевается под «Стандартной средой разработки», вообще неясно.

Автоматическое разбиение диска одинаково для всех трех вариантов поставки. Раздел /boot (и /boot/efi в случае использования UEFI) и том LVM, в котором только два раздела — корневой и своп. С этой схемой разметки я склонен не согласиться — хотелось бы иметь еще раздел /home. Впрочем, ничто не мешает разметить диск так, как удобно тебе. Кроме метода разбивки LVM, есть еще обычные разделы, динамический LVM и Btrfs. Само разбиение применяется только после нажатия кнопки «Начать установку».

После нажатия на данную кнопку начнется создание файловых систем и установка пакетов — весь процесс в моем случае занял 21 мин. Одновременно с этим процессом можно

Установка. Выбор пакетов

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

Установка наконец завершена. Жмем соответствующую кнопку и уходим на перезагрузку.

ПЕРВЫЙЗАПУСКИПЕРВЫЕВПЕЧАТЛЕНИЯ

Первый запуск длится примерно секунд 20 — не столь уж и бы-

Реинкарнация Красной Шапочки

Экран входа в систему

ной. Тем не менее некоторые вещи они убирать не стали — потому ли, что они являются фундаментальной частью третьего Гнома, или еще по какой причине — сие мне неведомо. К их числу относятся всплывающие при проведении мышью в определенной области экрана панели. Создание значков на рабочем столе, как и во всех остальных дистрибутивах, основанных на GNOME 3, не является интуитивно понятным.

Перейдем к основным приложениям. В качестве браузера используется Firefox 24 ESR — Red Hat, в отличие от Canonical,

не обновляет его на самую свежую версию просто из-за того, что она уже доступна. Проигрывание видео поддерживается из коробки, как и Java-апплеты (последние, впрочем, поддерживаются почти везде).

Email-клиент, как и в старых версиях, Evolution — стабильный, как и всегда. Как и многие другие почтовые клиенты, поддерживает автоматическое определение почтовых серверов при создании/добавлении учетной записи.

При попытке проиграть большинство локальных видеофайлов возникала проблема — отсутствуют кодеки. Впрочем, у Red Hat всегда была определенная позиция насчет них. Да и проигрывание музыки/видео на рабочей станции вещь совершенно не необходимая.

LibreOffice 4.1 без особых проблем открыл все мои docxфайлы, что и неудивительно. Файлы Visio тоже открылись без каких-либо затруднений.

А вот Nautilus меня огорчил — в первую очередь тем, что обзор сети Windows в нем сбоил. Ладно бы нельзя было под-

Окончание начальной конфигурации GNOME 3

ключиться к NAS по протоколу SMB вообще, так нет — пункт ниже, «Подключиться...», был вполне работоспособен. Более того, Nautilus так подвесил GNOME, что я счел необходимым перезагрузиться и не возиться с прибиванием зависших процессов. Однако все перечисленное может быть связано с тем, что тип подключения к сети, используемый в VirtualBox, в данном случае был NAT.

Хотелось бы также вспомнить об ACL, списках прав доступа, поддержка которых в Linux есть давным-давно, а вот стандартного графического интерфейса для их создания/редактирования не существует. В домашних условиях ACL, понятное дело, не нужен, но для корпоративных пользователей графический инструмент может быть весьма полезен.

В этой версии RHEL наконец появилось то, что во многих других дистрибутивах сделано уже давно, — автодополнение аргументов команд по нажатию клавиши табуляции. Забыл ты, допустим, ту или иную подкоманду systemctl — нажал Tab дважды, и появился их список.

Расскажу в двух словах и о KDE. При первом запуске его рабочий стол девственно чист — отсутствует даже корзина и ссылка на домашний каталог. Все нужно запускать из меню. Оно стандартно для четвертой версии KDE. Чересчур стандартно: при первом его вызове появляется «Избранное», в котором есть «Веб-браузер». Так вот, при нажатии на него запускается

Evolutionавтоматиче- вовсе не Firefox, что было бы логичным, а Konqueror. Нет, пой- скиопределяетнужные мите меня правильно, против него я ничего не имею. Но сама email-серверы политика корпоративного дистрибутива подразумевает некое единообразие, которого здесь не наблюдается. В остальном...

KDE можно смело советовать тем, кого раздражает GNOME 3, пускай его и попытались привести к привычному виду.

Однако стоит перейти к внутренностям RHEL 7.

ПОДКАПОТОМ

ЯдроиФС

Начнем с загрузчика. В качестве его используется Grub 2 с поддержкой UEFI и Secure Boot. Если раньше ты не имел дела с ним (маловероятно, но вдруг), нужно помнить, что ручками он уже не конфигурируется — для этого используются скрипты, на основе которых команда grub2-mkconfig генерирует файл конфигурации.

Ядро 3.10 в числе прочего поддерживает подписывание модулей, и в RHEL можно настроить параметры загрузки так, что неподписанные модули попросту невозможно будет загрузить. Для этого нужно добавить в параметр GRUB_CMDLINE_ LINUX в файле /etc/default/grub строчку "enforcemodulesig=1".

Как я уже писал выше, в качестве ФС по умолчанию в седьмой версии корпоративного дистрибутива используется XFS. Стоит рассказать о ней подробнее. XFS была разработана в 1993 году компанией SGI для своего варианта

Unixoid

UNIX — IRIX, и на тот момент это была действительно прогрессивная файловая система, поддерживающая работу с большими файлами (не забываем, что SGI специализировалась на графических рабочих станциях для создания видео с соответствующими требованиями). Годы спустя ее портировали и на Linux. Тем не менее еще в 2008 году были некоторые проблемы с производительностью (к настоящему времени они уже исправлены, в частности путем введения отложенной записи метаданных), и из-за них ФС уступала

вбыстродействии ext4. На текущий момент в восьмиядерной конфигурации XFS быстрее ext4 в два с лишним раза. Отмечу также, что ext4 имеет унаследованные проблемы на архитектурном уровне. Если же сравнивать с Btrfs, XFS выглядит гораздо более зрелой. Взять те же сервисные утилиты — они могут никогда и не понадобиться, но быть обязаны. Однако

вBtrfs отсутствует аналог debugfs, а в XFS он имеет место (xfs_db). Недостаток же у XFS тоже имеется — уменьшать размер ФС невозможно.

Сеть

Перейдем к сетевой подсистеме. Уже во время установки можно заметить, что сетевые интерфейсы именуются поновому. Связано это с тем, что в старой модели именования было неочевидно, какому физическому интерфейсу соответствует то или иное имя. Сейчас же имеется пять схем именования, которые выбираются systemd согласно определенным правилам. Схемы эти таковы:

1.Имена назначаются на основе номера встроенной сетевой карты, предоставляемого прошивкой или BIOS. Эта схема наиболее приоритетна, если не подходит — переходим ко второй схеме. Пример — eno1, где eno расшифровывает-

ся как ethernet on-board.

2.Имена назначаются на основе слота PCI-E, предоставляемого прошивкой, если эта схема не подходит — вступает в силу третья схема. Пример именования — ens1. Расшифровка буквы s — слот.

3.Устройства именуются согласно физическому расположению устройства. Пример — enp0s3, где p0s3 — расположение на шине PCI.

4.Если ни один из этих вариантов не подходит, применяется традиционная схема.

5.Есть еще альтернативная схема наименования на основе

MAC-адреса, например enx0800277b76b5.

В качестве средства конфигурирования сети (в том числе и всевозможной маршрутизации) используется Network Manager, что дает унификацию управления сетевыми устройствами. Старый способ, через скрипты ifcfg, по-прежнему поддерживается.

Брандмауэром теперь служит firewalld, фактически являющийся оберткой вокруг iptables. Он обеспечивает динамическое добавление правил (без перечитывания всего конфигурационного файла) и имеет интерфейс D-Bus, что позволяет запрашивать некоторым службам открытие тех или иных портов или выводить уведомления в трее. Команда firewall-cmd позволяет также выполнять команды, аналогичные таковым в iptables. На мой взгляд, однако, единственным преимуществом является только поддержка D-Bus, язык же описания правил достаточно скуден. Так что, если нужен именно хороший брандмауэр, не премину порекомендовать нормальную обертку вокруг iptables под названием shorewall.

Инструментарийуправленияимониторинга

Linux-системам давно не хватало некоего аналога WMI для абстрагирования от конфигурационных файлов. И такие инструменты начали появляться. Один из них был введен в новую версию RHEL — OpenLMI (Linux Management Infrastructure).

Если коротко, он состоит из двух частей — CIMOM, CIM Object Manager, которым является OpenPegasus, запускае-

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

•openlmi-account — управление пользователями;

•openlmi-logicalfile — чтение файлов и каталогов;

•openlmi-networking — управление сетью;

•openlmi-service — управление службами;

•openlmi-hardware — предоставление информации об оборудовании.

Основной язык написания провайдеров (иначе называемых агентами) — Python, хотя, разумеется, поддерживается и C/C++.

На стороне администратора запускается LMIShell, который представляет собой удобную CLI-оболочку, позволяющую, ко всему прочему, еще и писать скрипты. Поддержка WBEM и стандарта CIM автоматически подразумевает поддержку еще и CQL/WQL — подмножества SQL, разработанного специально для этого стандарта. Операторы, доступные в этом подмножестве: SELECT, WHERE, FROM, LIKE, логические (NOT, AND, OR). То есть в WQL доступно большинство базовых операторов SQL, кроме JOIN.

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

Архитектура OpenLMI соответствующего провайдера без проблем посмотреть хеш

Client System

WBEM Protocol HTTPS + CIM + XML

Managed Systems

Реинкарнация Красной Шапочки

SYN/ACK

Что нового в NewSQL?

ŭŨŤţŤŘŤřŤ ŘNEWSQL?

ПОГРУЖЕНИЕ В НОВЕЙШИЕ БАЗЫ ДАННЫХ

ют фатальным недостатком существующих БД стремление все хранить на диске. Если тебе нужно обрабатывать данные быстро, нужно хранить их в ОЗУ. А относительно небольшой объем ОЗУ на одной машине можно легко компенсировать, собрав кластер из сотен узлов. Хранение в ОЗУ не означает, что данные будут потеряны при выключении питания. Все эти БД ведут журнал операций и периодически скидывают снимки данных на диск. Мы рассмотрим VoltDB и MemSQL.

Другие разработчики NewSQL борются со сложностью развертывания и управления кластерной СУБД в современных виртуальных и облачных средах. Создаются красивые вебконсоли для управления и мониторинга. Рассмотрим в этом качестве NuoDB. Третьи разработчики NewSQL замахиваются на создание универсальных платформ для хранения, представления и обработки структурированных данных, в виде реляционной модели, но не только. Здесь мы познакомимся с замечательной FoundationDB. Итак, чтобы новая СУБД в полной мере могла называться NewSQL-решением, она должна быть SQL и NoSQL одновременно.

VOLTDB

VoltDB — это in-memory СУБД, написанная на Java. Это самая старая БД в нашем обзоре, первый публичный релиз состоялся аж в мае 2010 года. VoltDB также единственная СУБД в обзоре, полностью доступная под свободной лицензией (AGPL). Есть и проприетарная Enterprise-версия, в которую добавлены плюшки вроде VoltDB Web Studio — «среды разработки» в виде веб-приложения. В отличие от других СУБД, где на одном сервере ты можешь создать несколько баз данных, в VoltDB один процесс обслуживает одну базу. Точнее, множество процессов на множестве хостов кластера обслуживают одну базу, и других баз в этом кластере нет. Каждый процесс однопоточен, асинхронен, имеет свой каталог для хранения снапшотов, работает на одном CPU и называется партицией (partition). Соответственно, на каждом хосте кластера нужно запускать несколько процессов, согласно числу ядер CPU.

Сама БД описывается в виде каталога. В этом каталоге находится описание кластера: сколько узлов, сколько про-

SYN/ACK

Партицированные таблицы в VoltDB

VoltDB работает в кластере. И поэтому у него есть два типа таблиц: партицированные (partitioned) и реплицированные

(replicated)

ставляет собой транзакцию, и других транзакций нет. То есть весь набор доступных транзакционных действий мы определяем на этапе компиляции каталога БД. Хранимые процедуры являются частью сервера (вкомпилированы в сервер). «Пятью девятками» тут даже не пахнет: хочешь новую функцию — перекомпилируйся и перезапусти базу. Вся оптимизация вертится вокруг хранимых процедур.

Мультиверсионности нет, блокировок тоже, поскольку на партицию работает только один процесс и конкурировать ему не с кем. С одной стороны, пропускная способность действительно возрастает, и действительно уровень изоляции транзакций serialized. Хотя сложно говорить об уровне изоляции при фактически однопользовательской работе. Если запрос затрагивает несколько партиций, то это будет единственный запрос, выполняющийся в базе в этот момент. При таком подходе даже неудобно упоминать о разделении прав доступа к данным. Их тоже нет.

Вспомним про такое свойство транзакций, как durability: здесь оно реализовано через журнал транзакций и периодические снапшоты. Журнал хранится только со времени последнего снапшота, поэтому обращение к историческим данным невозможно. Надежность хранения достигается за счет резервирования данных на нескольких узлах кластера. Распределенные транзакции (да, они здесь возможны) фиксируются двухфазным коммитом.

Что собственно нового? Эта SQL БД работает в кластере. И поэтому у нас есть два типа таблиц: партицированные (partitioned) и реплицированные (replicated). С реплицированными таблицами (такие создаются по умолчанию, обычным CREATE TABLE) все просто — они целиком копируются на все узлы кластера. Это удобно для небольших таблиц-справоч- ников, с которыми часто делаются джойны и которые редко меняются. Партицированные таблицы шардируются между узлами кластера (точнее, между процессами-партициями). Шардируются по хешу ключа. Ключом может быть любой столбец таблицы с целочисленным или строковым значением (но не null). Ключ у таблицы может быть только один. В общем, таблица размазывается ровным слоем по всему кластеру (учитывая, конечно, K-factor).

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

Помни, что любое изменение структуры данных требует перекомпиляции каталога БД, а для некоторых (к примеру, добавление уникального индекса) требуется полный перезапуск базы. Такой подход к управлению структурой ну совсем не гибкий. Кроме того, поддерживать нормализованную реляционную схему для более-менее связных данных не представляется возможным: запросы ограничены по сложности, джойнить шардированные таблицы можно только по ключу шардинга и только на равенство. В update и delete подзапросы вообще запрещены. Кроме того, есть ограничения на размер резалт-сета — не более 50 Мб. Вдобавок VoltDB не поддерживает внешние ключи и check constraint, а уникальность записей для unique constraint обе-

спечивает только в пределах партиции. При этом заявляется, что СУБД поддерживает реляционную модель. Кодд переворачивается в гробу.

MEMSQL

MemSQL очень похожа на VoltDB. Тоже in-memory СУБД,

только написана на C++. Первый публичный релиз состоялся в июне 2012 года. У MemSQL имеется только проприетарная версия. Бесплатных версий нет, но есть триалка. В MemSQL узлы кластера неравнозначны. Здесь есть агрегаторы и ли-