Настройка конфигурации программного обеспечения компьютерных систем
Аннотация: Данная лекция посвящена стратегическому выбору и установке ОС (Unix, Linux, Windows), индивидуальным привязкам к узлам, синхронизации времени и системных файлов в системе, тиражированию ОС.
От вопросов, связанных с аппаратной составляющей кластера, перейдем к базовому и специализированному программному обеспечению. Заметим сразу, что в задачи данного раздела не входит обучение установке стандартных вариантов операционных систем. Это уже описано во множестве книг и предполагается, что читатель обладает необходимыми минимальными навыками и знаниями. Сосредоточимся на "кластерных" особенностях, позволяющих множеству независимых компьютеров согласованно работать в рамках единого комплекса.
Стандартом de-facto операционной системы для вычислительных кластеров в настоящее время является Linux. Какой дистрибутив предпочесть? Иногда это решает сам системный администратор , который будет поддерживать работу кластера, в некоторых случаях выбор однозначно определяется прикладным программным обеспечением, оптимизированным под конкретную версию ОС. С точки зрения собственно построения кластера большой разницы в дистрибутивах нет, однако специализированные прикладные пакеты могут оказаться к ним чувствительными. Это же касается и драйверов ко всему набору аппаратного обеспечения, особенно к новым моделям или нестандартному оборудованию.
В последнее время все большую популярность приобретает система Windows Compute Cluster Server 2003, разработанная компанией Microsoft для поддержки кластерных платформ. Вариант интересный, особенно если учесть большой объем прикладного ПО , работающего именно под MS Windows . Его миграция под кластерный вариант этого семейства операционных систем, безусловно, является лишь вопросом времени. Однако к настоящему моменту во всем мире опыта использования Windows Compute Cluster Server 2003 не много, система только недавно анонсирована, поэтому в данной работе мы будем предполагать, что выбрана ОС семейства Linux.
Рассматривая возможность использования продуктов подобного рода, нужно четко представлять возможные последствия этого решения. С одной стороны, необходимо понижать трудоемкость сопровождения и администрирования кластерных систем за счет автоматизации рутинных и предписанных регламентом процессов - это правильно, в таком направлении как раз и идет развитие данной области, в частности, для снижения стоимости владения сложными компьютерными системами. Но с другой стороны, кластерная система с самого начала должна быть максимально эффективной по отношению к задачам и оставаться такой все время своего существования. Значительным недостатком упомянутых выше продуктов является то, что в качестве основы коммуникационной среды везде предполагается Ethernet и взаимодействие через ТСР/IР, что может самым печальным образом сказаться на эффективности работы кластерной системы в целом. Если для работы в таком режиме система и ставилась, если есть уверенность, что все остается под контролем, или есть время для накопления опыта и экспериментов, то вполне можно воспользоваться и таким путем.
Установив и настроив обычный вариант операционной системы на головном узле кластера, проведем аналогичную операцию на файловом сервере. Настоятельно рекомендуем использовать Logical Volume Manager для раздела, на котором будут располагаться данные пользователей кластера. Это позволит легко проводить дальнейшее расширение хранилища и безболезненно переносить логический раздел с данными пользователей в будущем.
На головную машину операционная система ставится обычным образом. А вот для того, чтобы установить ОС на вычислительные узлы кластера, как правило, требуются дополнительные усилия. С одной стороны, на вычислительных узлах не принято устанавливать привычные в такой ситуации CD или Floppy-приводы, а с другой - установить и настроить ОС на десятках узлов само по себе является занятием долгим и утомительным.
Для упрощения процесса можно воспользоваться виртуальными приводами, если они поддерживаются сервисной сетью. Если нет, то достаточно подключить через USB или напрямую к одному из узлов CD-привод и провести установку операционной системы на этом узле.
Проведя начальную установку и стандартную настройку узла, нужно сделать еще несколько шагов для его дальнейшей работы в составе кластера. Убедитесь, что на узле установлен сервер ssh , и что пользователю root разрешен удаленный вход. Настройте беспарольный вход на узел для пользователя root , используя авторизацию по ключу, для чего воспользуйтесь командой ssh - keygen . Необходимо иметь возможность заходить на этот узел привилегированным пользователем root с головного узла - это значительно облегчит жизнь в дальнейшем.
Настройте на файловом сервере сетевой каталог, разрешив доступ к нему с вычислительных узлов и головного узла. Это можно сделать, прописав соответствующую строку в файл /etc/exports и запустив сервер NFS . Убедитесь, что сервер NFS стартует автоматически при загрузке файл-сервера .
Крайне желательно добавить в строку экспорта в файле /etc/exports опцию no_root_squash . По умолчанию NFS отменяет права суперпользователя для удаленных хостов, а указанная опция не позволяет этого сделать.
На вычислительном и головном узлах создайте каталог с одинаковым именем (например, /common или даже /home ) и настройте автоматическое монтирование в него каталога с файл-сервера . Это можно сделать, прописав соответствующую строку в файл /etc/fstab . Убедитесь, что каталог монтируется без проблем, до того как будете перезагружать узлы!
Обратите внимание на то, что многие современные дистрибутивы (такие как SuSE, RedHat, Fedora Core и другие) делают жесткую привязку настроек сетевого интерфейса к МАС-адресу сетевой карты . Если просто скопировать такие настройки на другой узел, сетевой интерфейс просто не заработает. Для того чтобы настройки можно было безболезненно перенести на любой узел, необходимо убрать привязку к МАС-адресу из файла /etc/sysconfig/network/ifcfg-eth-XXXXXX , если она там есть, переименовать этот файл в ifcfg-eth0 или ifcfg-ethl . Точно также необходимо убрать явные переименования сетевых интерфейсов в подсистеме udev . Чтобы найти остальные не столь очевидные привязки к МАС-адресу, поищите все его упоминания командой 'grep -ri MAC /etc' , где MAC замените реальным значением МАС-адреса. Узнать его можно командой ifconfig .
Синхронизация времени в системе. Она осуществляется с помощью пакета xntp или его аналогов. При существенном расхождении часов на различных узлах могут наблюдаться сбои в работе параллельных программ . Необходимо настроить ntp - сервер на головном узле, а на всех остальных узлах - клиентов, которые будут с ним синхронизироваться. При старте все узлы должны явно синхронизироваться с головным узлом командой ntpdate (она обычно входит в состав пакета xntp ), что необходимо, поскольку при большом расхождении часов клиент ntp коррекцию времени может и не выполнить.
Отслеживание состояния UPS. Большинство современных источников бесперебойного питания способны сообщать о своем текущем состоянии через СОМ-порт, USB или по сети через SNMP . Некоторые производители включают программы под Linux для отслеживания состояния UPS в поставку, но, увы, делают это далеко не все. Существует свободный пакет для мониторинга состояния UPS , который называется NUT. Он поддерживает большое число моделей UPS , но перед покупкой оборудования лучше проверить, поддерживается ли конкретная модель. NUT включает в себя сервер , снимающий данные с UPS , и клиентов. Сервер работает на головном узле, к нему же должен быть подключен управляющий кабель UPS . Клиенты должны быть установлены на все узлы. В случае отключения питания клиенты дадут команду на выключение узлов. Таким образом, можно избежать потери данных и сохранить работоспособность кластера. Если UPS достаточно мощный и может поддерживать работу кластера в течение какого-то времени, то команда выключения узлов может быть настроена на отсроченное выключение. В этом случае, если электропитание восстановится, то выключение будет отменено.
Синхронизация системных файлов ( passwd, shadow, hosts, .. .). Для того, чтобы системные изменения затрагивали не только головной узел, но весь кластер сразу, можно применять различные схемы. NIS - это одно из самых простых решений, которое, однако, чревато проблемами в случае сетевых сбоев. Следует специально отметить, что, несмотря на "простоту", хорошая настройка этой схемы может оказаться весьма нетривиальным делом для неискушенного администратора. Использование rsync является более простым решением, требующим лишь включения нужного сервиса на всех узлах и начальной настройки на головном узле. Третий вариант можно условно назвать "ручным" копированием, что предполагает использование scp в скрипте для автоматического дублирования всех нужных файлов на узлы. Каждый из перечисленных методов требует явного вызова определенной команды после изменения системных файлов. Есть и другие методы, но все они, в целом, аналогичны rsync .
Следующим шагом в настройке программного обеспечения кластерной системы является тиражирование установленной ОС на все остальные узлы. Для этого можно воспользоваться тремя схемами.
- Берем любой доступный компьютер. Вставляем в него жесткий диск из вычислительного узла с уже настроенной ОС и один (или несколько) дисков из других узлов. Затем с помощью команды dd копируем на чистые диски содержимое первого диска.
- Можно воспользоваться программой типа Acronis True Image или Norton Ghost для клонирования диска первого узла на диски остальных узлов.
- Можно создать образ установленной ОС с помощью архиватора tar или cpio (исключите при архивировании содержимое файловых систем proc , sysfs, devfs, usbfs и им подобных). Установите syslinux . С помощью пакета sysinux и серверов dhcpd настройте сетевую загрузку. Далее нужно создать сетевой NFS-диск, на котором будет создана минимальная система, достаточная для подготовки жесткого диска (разбиение и форматирование), для разворачивания архива с образом ОС и установки загрузчика . Убедитесь, что ядро данной минимальной системы поддерживает корневой каталог на NFS. Затем скопируйте в каталог сетевого диска образ ОС и в качестве стартового сделайте скрипт, который автоматически установит это образ. После этого произведите сетевую загрузку всех узлов, где операционная система еще не установлена.
Третий способ, конечно, сложнее, но он более универсален и позволяет в дальнейшем быстро добавлять новые узлы и восстанавливать испорченные простой перезагрузкой (с указанием "грузиться по сети"). Для подготовки минимальной системы, которая будет грузиться по сети и устанавливать ОС на узлы, можно воспользоваться любым мини-дистрибутивом из сети Интернет или подмножеством программ из уже имеющегося дистрибутива.
В минимальной системе обязательно должны присутствовать: bash, tar (или cpio ), sfdisk, mke2fs ( mkreiserfs или иное в зависимости от выбранной файловой системы), полный пакет grub (или lilo ) и набор библиотек с динамическим линкером, необходимые для работы этих программ.
С помощью программы sfdisk можно записать в файл разметку жесткого диска с первого узла и в стартовом скрипте использовать ее для разметки жестких дисков чистых узлов.
О безопасности кластера нужно позаботиться заранее. Не стоит полагаться на соображения типа: "Да кому нужно взламывать наш кластер ?". Будьте уверены, что желающих найдется много. Совсем не обязательно их целью будет помешать вашей работе. Скорее всего, задачей станет использовать взломанные компьютеры как плацдарм для будущих хакерских действий или рассылки спама.
О том, как повысить безопасность Linux-сервера, написано немало книг и статей, желательно с ними ознакомиться. Приведем лишь несколько основных советов.
- Для удаленного входа на кластер и удаленной передачи файлов используйте ssh . Под Windows есть немало программ, реализующих этот протокол, например, свободно распространяемая программа putty . He используйте для этих целей telnet, ftp, nfs или samba (windows share).
- Отключите все ненужные сервисы.
- Включите файрволл, продумайте политику его использования.
- По возможности, дополнительно ограничьте доступ пользователей. Это можно сделать, задав список адресов, с которых разрешено заходить на головной узел, либо запретив авторизацию по паролю и обязав пользователей использовать для авторизации ключи.
- Включите "устаревание" паролей пользователей.
- Включите проверку сложности паролей.
- Установите одну из программ проверки целостности системы (такую, как tiger, ossec, tripware ).
- Регулярно проверяйте журналы на головном узле, воспользуйтесь пакетом logcheck или logwatch .
- Время от времени проверяйте систему на наличие "закладок" программами типа chkrootkit, rkhunter . He храните эти программы в доступном с головного узла каталоге, лучше запускайте их с USB-Flash или с дискеты.
О том, как произвести такие настройки, можно прочесть в man-страничках chage, sshd, sshd_config, pam , а также В документации к упомянутым пакетам. Подчеркнем еще раз: обеспечение безопасности - это очень важный вопрос. Сразу уделите безопасности особое внимание, поскольку решение этих проблем после обнаружения факта взлома уже может быть сопряжено с потерями.
В данном разделе мы сразу предположили использование NFS в качестве сетевой файловой системы кластера. Она хорошо известна, у многих есть опыт ее использования, поэтому именно на NFS чаще всего останавливается выбор администраторов. Но хочется предостеречь сразу: этот вариант, во-первых, не единственный и, во-вторых, совсем не идеальный. Основное слабое место связано с плохой масштабируемостью NFS и очень сильным падением характеристик ее работы при увеличении числа узлов. Какова цель кластерного проекта и чего хотелось бы достичь? Максимум процессоров, максимум "флопсов"? Бывает и такое. В частности, именно такие требования выдвигают некоторые масштабные задачи физики высоких энергий, для которых чем больше в компьютерной системе вычислительных узлов, тем лучше. Если говорить про общий случай, то каждое приложение устанавливает некоторый порог, соотношение между вычислительными способностями кластера и характеристиками подсистем ввода/вывода, за которым выполнение приложения перестает быть эффективным, а использование кластера становится полностью нецелесообразным. Для параллельных приложений порог может меняться в зависимости от числа используемых процессоров, что создает дополнительные трудности в его определении на практике. Но сделать это необходимо, причем сделать на этапе проектирования архитектуры, чтобы вместо сбалансированной кластерной системы не получить однобоко развитого монстра. Здесь уместно вспомнить определение суперкомпьютера, приведенное в предисловии данной книги, согласно которому в системах подобного класса "проблема вычислений сводится к проблеме ввода/вывода".
Альтернативные варианты файловых систем, к которым стоит приглядеться: Panasas File System , Lustre, Terragrid, Parallel Virtual File System (PVFS2), General Parallel File System (GPFS). Данные файловые системы изначально предназначались для параллельных компьютеров, они активно развиваются и реально используются на многих больших кластерных системах. Имеет смысл подумать об этих вариантах. Сделать "как все" не означает принять оптимальное для себя решение: не исключено, что именно данные файловые системы лучше всего подойдут для решения задач проекта.
Итак, на все узлы кластера установлена операционная система , проведена начальная настройка, кластер "задышал". Следующим шагом будет переход к содержательной работе кластера и запуск параллельных программ . Для этого нам нужен набор компиляторов, одна или несколько сред параллельного программирования, дополнительные библиотеки и пакеты, специализированные прикладные системы.
- Конфигурация программного обеспечения — совокупность настроек программы, задаваемая пользователем, а также процесс изменения этих настроек в соответствии с нуждами пользователя.
Существуют различные подходы к хранению конфигурации. Многие программы хранят настройки в текстовых файлах, что особенно характерно для UNIX-подобных ОС. В ОС Windows текстовые конфигурационные файлы также используются и часто имеют формат .ini. Несмотря на то, что почти во всех случаях эти файлы можно изменять вручную, во многих случаях для этого создаётся специальный интерфейс (который может быть как консольным, так и графическим).
Иногда в UNIX-подобных ОС конфигурация задаётся на этапе сборки программы, и для её изменения программу необходимо пересобирать. Ярким примером может служить ядро Linux. Почти для всех программ, собираемых с использованием сценариев autoconf, можно подключать или отключать те или иные внешние библиотеки, указывая параметры для сценария configure.
Связанные понятия
Монтирование файловой системы — системный процесс, подготавливающий раздел диска к использованию операционной системой.
Дамп памяти (англ. memory dump; в Unix — core dump) — содержимое рабочей памяти одного процесса, ядра или всей операционной системы. Также может включать дополнительную информацию о состоянии программы или системы, например значения регистров процессора и содержимое стека. Многие операционные системы позволяют сохранять дамп памяти для отладки программы. Как правило, дамп памяти процесса сохраняется автоматически, когда процесс завершается из-за критической ошибки (например, из-за ошибки сегментации.
Ярлы́к (англ. shortcut) — файл, служащий указателем на объект (например, файл, который требуется определённым образом обработать), программу или команду и содержащий дополнительную информацию.
Исполняемый файл (англ. executable file, также выполняемый, реже исполнимый, выполнимый) — файл, содержащий программу в виде, в котором она может быть исполнена компьютером. Перед исполнением программа загружается в память, и выполняются некоторые подготовительные операции (настройка окружения, загрузка библиотек).
Установка программного обеспечения, инсталляция — процесс установки программного обеспечения на компьютер конечного пользователя. Выполняется особой программой (пакетным менеджером), присутствующей в операционной системе (например, RPM, APT или dpkg в Linux, Установщик Windows в Microsoft Windows), или же входящим в состав самого программного обеспечения средством установки. В операционной системе GNU очень распространено использование системы GNU toolchain и её аналогов для компиляции программного.
Файловый дескриптор — это неотрицательное целое число. Когда создается новый поток ввода-вывода, ядро возвращает процессу, создавшему поток ввода-вывода, его файловый дескриптор.
Точка монтирования (англ. mount point) — это каталог или файл, с помощью которого обеспечивается доступ к новой файловой системе, каталогу или файлу.
По умолча́нию — термин, используемый для обозначения значений параметров какой-либо программы, предустановленных разработчиком. Пользователь может изменить эти установки явным образом, однако, если он не сделал этого, то в качестве значений используются параметры, заданные разработчиком.
Символическая («мягкая») ссылка (также «симлинк», от англ. Symbolic link) — специальный файл в файловой системе, в котором вместо пользовательских данных содержится путь к файлу, открываемому при обращении к данной ссылке (файлу).
Переменная среды́ (англ. environment variable) — текстовая переменная операционной системы, хранящая какую-либо информацию — например, данные о настройках системы.
Конте́кстное меню́ — элемент графического интерфейса операционной системы, представляющий собой список команд, вызываемый пользователем для выбора необходимого действия над выбранным объектом. Команды контекстного меню относятся к тому объекту, над которым это меню было вызвано.
О программном обеспечении рассказывает другая статья.Переносимое приложение (также портативное, автономное, и — неточно, в качестве кальки — портированное; англ. portable application, portable app) — программное обеспечение, которое для своего запуска не требует процедуры установки и может полностью храниться на съёмных носителях информации, что позволяет использовать данное ПО на многих компьютерах. Переносимое приложение может быть настроено так, чтобы считывать свои конфигурационные настройки.
Динамический сайт — сайт, состоящий из динамичных страниц — шаблонов, контента, скриптов и прочего, в большинстве случаев в виде отдельных файлов (в Lotus Notes/Domino данные и все элементы дизайна, включая пользовательские скрипты, хранятся в одном файле).
Двоичный (бинарный) файл — в широком смысле: последовательность произвольных байтов. Название связано с тем, что байты состоят из бит, то есть двоичных (англ. binary) цифр.
Файл регистрации (протокол, журнал, лог; англ. log) — файл с записями о событиях в хронологическом порядке, простейшее средство обеспечения журналирования. Различают регистрацию внешних событий и протоколирование работы самой программы — источника записей (хотя часто всё записывается в единый файл).
Блокнот (англ. Notepad) — простой текстовый редактор, являющийся частью операционных систем Microsoft Windows, начиная с вышедшей в 1985 году Windows 1.0.
Упако́вка исполняемых фа́йлов заключается в сжатии исполняемого файла и прикреплении к нему кода, необходимого для распаковки и выполнения содержимого файла. Упаковка применяется по ряду причин.
DLL (англ. Dynamic Link Library — «библиотека динамической компоновки», «динамически подключаемая библиотека») в операционных системах Microsoft Windows и IBM OS/2 — динамическая библиотека, позволяющая многократное использование различными программными приложениями. Эти библиотеки обычно имеют расширение DLL, OCX (для библиотек содержащих ActiveX), или DRV (для ряда системных драйверов). Формат файлов для DLL такой же, как для EXE-файлов Windows, т. е. Portable Executable (PE) для 32-битных и 64-битных.
Механизм копирования при записи (англ. Copy-On-Write, COW) используется для оптимизации многих процессов, происходящих в операционной системе, таких как, например, работа с оперативной памятью или файлами на диске (пример — ext3cow).
Ассоциация или ассоциирование файлов — в программном обеспечении привязывание файла (по расширению или по каким-либо другим признакам) к прикладной программе, которая обрабатывает эти файлы. При «вызове» этого файла, например, в файловом менеджере, вызовется связанная с ним программа и откроет файл.
Корзи́на — элемент графического интерфейса пользователя, предназначенный для удаления и, часто, временного хранения удалённых объектов (в некоторых реализациях — только файлов и каталогов). Корзина в ряде систем позволяет восстановить недавно удалённый объект в случае ошибки или недоразумения пользователя.
Дизассе́мблер (от англ. disassembler ) — транслятор, преобразующий машинный код, объектный файл или библиотечные модули в текст программы на языке ассемблера.
Загрузка по сети — это процесс загрузки компьютера из сети без использования жесткого диска. Данный метод загрузки может быть использован в маршрутизаторах или в бездисковых рабочих станциях, а также в публичных компьютерах, которые работают, например, в школах или библиотеках. Применяют данную технологию.
Снимок файловой системы, или снапшот, или снепшот (от англ. snapshot — мгновенный снимок), — моментальный снимок, копия файлов и каталогов файловой системы на определённый момент времени.
Вкла́дка (англ. tab) — элемент графического интерфейса пользователя, который позволяет в одном окне приложения переключение между несколькими открытыми документами или предопределёнными наборами элементов интерфейса, когда их доступно несколько, а на выделенном для них пространстве окна можно показывать только один из них.
Виртуальная файловая система (англ. virtual file system — VFS) или виртуальный коммутатор файловой системы (англ. virtual filesystem switch) — уровень абстракции поверх конкретной реализации файловой системы. Целью VFS является обеспечение единообразного доступа клиентских приложений к различным типам файловых систем. VFS может быть использована для доступа к локальным устройствам и файлам (fat32, ext4, ntfs), сетевым устройствам и файлам на них (nfs), а также к устройствам, не предназначенным для.
В программировании именованный канал или именованный конвейер (англ. named pipe) — один из методов межпроцессного взаимодействия, расширение понятия конвейера в Unix и подобных ОС. Именованный канал позволяет различным процессам обмениваться данными, даже если программы, выполняющиеся в этих процессах, изначально не были написаны для взаимодействия с другими программами. Это понятие также существует и в Microsoft Windows, хотя там его семантика существенно отличается. Традиционный канал — «безымянен.
Модуль ядра, загружаемый модуль ядра (англ. loadable kernel module, LKM) — объект, содержащий код, который расширяет функциональность запущенного или т. н. базового ядра ОС. Большинство текущих систем, основанных на Unix, поддерживают загружаемые модули ядра, хотя они могут называться по-разному (например, kernel loadable module в FreeBSD и kernel extension в Mac OS X).
Бу́фер обме́на (англ. clipboard) — промежуточное хранилище данных, предоставляемое программным обеспечением и предназначенное для переноса или копирования между приложениями или частями одного приложения через операции вырезать, копировать, вставить.
Загрузчик операционной системы — системное программное обеспечение, обеспечивающее загрузку операционной системы непосредственно после включения компьютера (процедуры POST) и начальной загрузки.
Эмулятор терминала, приложение терминала, term или tty для краткости — это программа, которая эмулирует терминал компьютера внутри некоторой другой архитектуры вывода данных на экран.
Уровень абстракции — один из способов сокрытия деталей реализации определенного набора функциональных возможностей. Применяется для управления сложностью проектируемой системы при декомпозиции, когда система представляется в виде иерархии уровней абстракции.
Командный интерпретатор, интерпретатор командной строки — компьютерная программа, часть операционной системы, обеспечивающая базовые возможности управления компьютером посредством интерактивного ввода команд через интерфейс командной строки или последовательного исполнения пакетных командных файлов.
Планировщик задач — программа (служба или демон), часто называемая сервисом операционной системы, которая запускает другие программы в зависимости от различных критериев, как, например.
Стандартные потоки ввода-вывода в системах типа UNIX (и некоторых других) — потоки процесса, имеющие номер (дескриптор), зарезервированный для выполнения некоторых «стандартных» функций. Как правило (хотя и не обязательно), эти дескрипторы открыты уже в момент запуска задачи (исполняемого файла).
Око́нный интерфе́йс — способ организации полноэкранного интерфейса программы (разновидность графического интерфейса), в котором каждая интегральная часть располагается в графическом окне — собственном субэкранном пространстве, находящемся в произвольном месте «над» основным экраном. Несколько окон, одновременно располагающихся на экране, могут перекрываться, виртуально находясь «выше» или «ниже» друг относительно друга.
Журналирование (англ. logging) — форма автоматической записи в хронологическом порядке операций в информационных технологиях, процесс записи информации о происходящих в рамках какого-либо процесса с некоторым объектом событиях, например, в файл регистрации или в базу данных. В некоторых программный комплексах используется термин "аудит", что является не верным, поскольку аудит подразумевает сравнение чего-то с чем-то, чего-то на предмет соответствия, например, требованиям, иными словами это корреляционный.
Загрузочный сектор, бутсектор (англ. boot sector, Volume boot sector (Volume boot record), Partition boot sector) — это особый сектор на жёстком диске, дискете или другом дисковом устройстве хранения информации. (Для дискеты это первый физический сектор, для жёсткого диска — первый физический сектор для каждого раздела.) В процессе загрузки компьютера с дискеты он загружается в память программой POST (в компьютерах архитектуры IBM PC обычно с адреса 0000:7c00), ему передается управление командой.
Общий ресурс, или общий сетевой ресурс, — в информатике, это устройство или часть информации, к которой может быть осуществлён удалённый доступ с другого компьютера, обычно через локальную компьютерную сеть или посредством корпоративного интернета, как если бы ресурс находился на локальной машине.
Графические форматы делятся на векторные и растровые. Большинство графических форматов реализуют сжатие данных (одни — с потерями, другие — без).
А́дресное пространство (англ. address space) — совокупность всех допустимых адресов каких-либо объектов вычислительной системы — ячеек памяти, секторов диска, узлов сети и т. п., которые могут быть использованы для доступа к этим объектам при определенном режиме работы (состоянии системы).
Объе́ктный мо́дуль (также — объектный файл, англ. object file) — файл с промежуточным представлением отдельного модуля программы, полученный в результате обработки исходного кода компилятором. Объектный файл содержит в себе особым образом подготовленный код (часто называемый двоичным или бинарным), который может быть объединён с другими объектными файлами при помощи редактора связей (компоновщика) для получения готового исполнимого модуля либо библиотеки.
Декомпиля́тор — это программа, транслирующая исполняемый модуль (полученный на выходе компилятора) в эквивалентный исходный код на языке программирования высокого уровня.
Архив — это файл, содержащий в себе один или несколько других файлов и/или папок, а также метаданные. Архивы используются для объединения множества любых файлов в единый файл-контейнер с целью удобства хранения и переноса информации или просто чтобы сжать данные. Для создания архивов и работы с ними используются программы-архиваторы.
Жёсткой ссылкой (англ. hard link) в UFS-совместимых файловых системах называется структурная составляющая файла — описывающий его элемент каталога.
Проверка системных файлов (SFC) — это утилита Microsoft Windows, позволяющая пользователю находить и восстанавливать повреждения системных файлов Windows. Компонент доступен в Windows 98, Windows 2000 и всех последующих версиях операционных систем семейства Windows NT. В Windows Vista и Windows 7 проверка системных файлов встроена в защиту ресурсов Windows, которая защищает не только критичные системные файлы, но и ключи реестра, и папки. Под Windows Vista, sfc.exe может быть использован для проверки.
Самораспаковывающийся или самоизвлекающийся архив (англ. self-extracting archive, сокращённо «SFX archive») — файл, компьютерная программа, объединяющая в себе архив и исполняемый код для его распаковки. Такие архивы, в отличие от обычных, не требуют отдельной программы для их распаковки (получения исходных файлов, из которых они созданы), если исполняемый код можно выполнить в указанной операционной системе. Это удобно, когда неизвестно, есть ли у пользователя, которому передаётся архив, соответствующая.
Закладка (англ. bookmark) — избранная, любимая интернет-ссылка в браузере или выбранное место (позиция) в тексте.
Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.
Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.
А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.
Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.
Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.
Что такое CM и зачем он нужен
Управление конфигурацией
Для начала определимся, что такое configuration, ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».
В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.
Версия – это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.
Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.
В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).
Схема 1. Элементы, их версии и срезы-конфигурации.
CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.
Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.
Так в чем же заключается такая ценность CM?
Направления ответственности CM
Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.
Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.
Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.
Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.
Средства контроля изменений и обеспечения версионности создают условия для распараллеливания разработки в больших командах. Это достигается благодаря тому, что, описав эти средства, мы даем разработчикам документированные процедуры, позволяющие разделять ответственность и ограничивать области деятельности каждого из разработчиков.
Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.
Итак, каковы задачи управления конфигурацией?
- идентификация рабочих продуктов;
- стабилизация результатов работы и определение базы для дальнейшей работы;
- отслеживание запросов на изменение;
- контроль версий;
- обеспечение параллельности разработки;
- сбор метрик и формализация применяемых методов.
Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.
Ссылки для расширения кругозора:
-
Software Configuration Management на Википедии. Software Engineering Book of Knowledge. SEI CMMI Website. CM Crossroads the Configuration Management Community.
Abstract: как заставить себя изучить любую из существующих систем конфигураций и перестать редактировать файлы на сервере руками.
Пост посвящён душевной боли, которую нужно преодолеть. Ещё в посте будет чуть-чуть технического, но большей частью пост посвящён борьбе с самим собой, отложенному вознаграждению и тому, насколько моторная память котролирует вас.
Уже многие годы (по айтишным меркам — три поколения как) существуют программы, которые позволяют автоматизировать процесс конфигурации серверов. Все эти программы сложные, они вторгаются в святую святых администраторов и заставляют их делать "всё не так, как раньше". Их изучение и интернализация (признание, что "так надо и так правильно") — абсолютный must have в карьере любого системного администратора.
Главная боль состоит в том, что система управления конфигурациями ломает привычную автоматику пальцев. Раньше вы могли поднять веб-сервер за 2 минуты почти не глядя на экран. Теперь вам предлагают потратить на абсолютно те же самые действия минут 15-20 (если вы хорошо знаете систему управления конфигурациями) или даже несколько дней (. ), если вы её изучаете.
Это преступление против личной эффективности. Уменьшить её в десять (0xA) раз — и это они называют прогрессом?
Ещё хуже: часто эти простыни будут касаться не ваших действий, а совершенно несвязных изменений в других местах проекта. И вы будете вынуждены с ними разбираться. Иногда это будут даже баги системы управления конфигурациями и вы будете чинить/обходить баги вместо того, чтобы заниматься своей прямой работой.
Ну как, я "продал" вам эту технологию? Готовы отбиваться всеми силами от попыток внедрить её на рабочем месте?
Перед тем, как мы продолжим говорить про системы управления конфигурациями, я хочу показать на очень иллюстративный пример из психологии зефирный эксперимент. Для тех, кому лениво читать Википедию, пересказ: детям дают зефирку, и говорят, что если они её не съедят за 15 минут, то им дадут вторую (и обе можно будет съесть). Чем старше ребёнок, тем больше вероятность, что он продержится 15 минут. Малыши не могут себя сдержать и съедают зефирку сразу, хотя потом становится обидно. Этот эксперимент проверяет механизм "отложенного удовольствия".
Именно это и предлагают системы управления конфигурациями. Вы тратите пол-часа на операцию, которую вы можете руками сделать за 3 минуты, а потом эту операцию можно выполнять снова и снова (когда нужно) без затраты трёх минут. И главное, без вовлечения головы. Чаще всего эту процедуру делегируют CI-серверу (jenkins, buildbot, etc), и тогда это открывает дверь для первого шажка к волшебной двери по имени CI/CD.
А этот шажок называется 'staging'. Копия вашего продакшена, которая ничем не занимается. На которой вы можете посмотреть ответ на вопрос "что будет, если я поменяю версию сервера?" и другие смешные эксперименты, не сломав ваш продакшен.
Безусловно, staging можно сделать и без систем управления конфигурациями. Но кто будет следить за тем, что staging похож на продакшен? Более того, кто будет следить, что после вашего смешного эксперимента стейджинг всё ещё похож на продакшен? Если вы делаете смешной эксперимент на результате предыдущего смешного эксперимента, то возможно, результат будет отличаться от того, что получится потом на продакшене.
Этот вопрос "кто будет следить?" на самом деле с подковыркой. Если у вас не гигантский раздутый штат в котором у вас может быть пара человек, которые следят за staging'ом, то ответ на него "никто". Никто не следит. Что же делать?
Ответ: "до основанья мы разрушим," и пересоздадим с нуля. Если в этом процессе от человека требуется больше минуты времени, то, разумеется, никто этого делать не будет. Слишком уныло снова и снова делать то же самое ради исправления "смешного эксперимента".
Обычная мысль "Да чего его переподнимать, я сейчас всё назад верну руками, так быстрее". На выходе — смешной эксперимент и результат его исправления, вместо "копии продакшена".
А вот если есть робот, который "пойдёт и всё сделает сам", вот тогда да, никакой проблемы. Пошёл и сделал.
Если переподнять стейджинг так просто, то почему бы его не поднять в ещё одном экземпляре? Он может быть попроще, в нём не будет какой-то из важных сложных тяжёлых компонент, но нужный кусок, над которым вы работаете прямо сейчас — почему бы и нет?
А ещё он может быть на localhost'е, в виртуалке или контейнере. Что даёт вам практически нулевую латенси при работе (приятно), поддержку оффлайнового режима (полезно). Это потребует чуть-чуть работы с системой управления конфигурациями, но куда меньше, чем может показаться. А дальше — тык-тык и у вас свежий кусок копии продакшена (или даже чего-то специфичного для вашего фичебранча из гита).
После того, как у вас есть написанный процесс превращения нескольких серверов в продакшен и вы можете повторять его снова и снова (малыми усилиями), вы вольны начинать менять кусочки этого процесса (на более удобный/правильный/модный процесс) и смотреть что получилось.
Это требует второй части системы управления конфигурациями — валидации серверов. Об этом мы поговорим чуть позже, но пока сфокусируйтесь на простой идее: вы можете попробовать поменять что-то в процессе конфигурации сервера и посмотреть что получится. За бесплатно. (От себя: когда я не уверен, я иногда запускаю 2-3 версии в параллель на разных стейджингах чтобы выбрать лучший).
Рефакторинг и хранение инструкций для системы управления конфигурациями в гите делает возможным проводить code review (если у вас больше одного человека в команде). code review это круто! Во-первых он дисциплинирует не оставлять кривизны. Во-вторых вы учитесь у друг друга как делать лучше. В третьих это увеличивает взаимное знание о проекте и происходящих в нём изменениях. Развивая линию ci/cd, с некоторыми усилиями можно даже видеть результаты прогона предлагаемых изменений на временной инсталляции — и робот может завернуть pull request просто потому, что он "всё ломает" — no human involved.
Если у нас есть набор инструкций для системы управления конфигурацией, то мы можем проверить результат. Для этого есть масса интересных решений: testinfra, goss, inspec, serverspec, etc. Фактически, эти тесты позволяют проверить результат применения вашей конфигурации. Например, "на 80ом порту слушают", "в мониторинге появилось 180 чеков", "пользователь Х может залогиниться на сервер" и т.д. Когда у вас появляются такие тесты, то вы можете уже сколько угодно играться с процессом — если тесты проходят, то вы всё сделали правильно. Благодаря этому, вы можете пробовать новое (дерзкое) и не бояться неожиданного (например, "ой, я же не подумал, что включение SSL сломает весь мониторинг").
Системы управления конфигурациями напрямую угрожают рабочим местам низкоквалифицированных системных администраторов. Если раньше нам нужно было 20 администраторов, каждый из которых мог управлять 20 серверами, то теперь команда из трёх (чуть-чуть более квалифицированных администраторов) прекрасно может справляться с 400 серверами. На самом деле один тоже может справляться, но 2-3 дают большую компетенцию команде, меньший бас-фактор (концентрацию знаний у единственного человека) и улучшают атмосферу в коллективе благодаря взаимной ответственности за качество работы. И с job security всё просто. Либо вы в списке этих трёх администраторов, либо нет.
На самом деле я чуть-чуть лукавлю и реальность обычно выглядит так: вместо 60 серверов у трёх администраторов у них на руках оказывается 400 (1000? 2000?) серверов, и варианта "нанять ещё 17 администраторов" просто не стоит по бюджетным причинам. Но это особенности растущего рынка и дефицита квалифицированных кадров, а общий аргумент всё равно остаётся: системы управления конфигурациями повышают эффективность труда, и на рынке оказываются более востребованы люди с более высокой эффективностью труда.
При всей позитивности необходимости вышесказанного, любая система управления конфигурациями — всего лишь программа. Это означает, что будут баги. В том числе обидные требующие делать неудобно и некрасиво лишь бы обойти баг. Это означает, что очевидные архитектурные фичи не будут реализованы просто потому, что у программистов иное видение направления движения проекта. Это означает, что вместо части документации будет "Документация" (которая находится в каталоге src ). Как любая другая программа, она будет требовать внимания к своему внутреннему миру, уделения себе времени, компетенции (и ещё времени на обучение).
Всё это (включая баги и глубокий внутренний мир) — потребует адаптации мышления под модель, которая диктуется системой управления конфигурации. Управление конфигурациями — крайне инвазивная сущность, которая хочет быть главной во всём, и многие рабочие процессы придётся подстраивать под требования этой программы. Будет множество граничных моментов, когда станет хуже (раньше можно было сделать лучше и проще), будет множество раз, когда будет ощущение выполнения нелепого ритуала вместо нормальной работы.
Но вместе с этим будет и ещё одно ощущение — что стало меньше кнопкодавства и стало больше думания. Вместо "пойти и поменять" будет момент размышления "а правильно ли менять так?", "А почему его вообще надо менять?", будет больше рассуждений об архитектуре (почему на сервере А мы меняем одно значение а на сервере Б другое? Можем ли мы найти что-то общее между этими изменениями и описать это общее как новую сущность?)
Онтологические проблемы будут в полный рост. Размышления над "общим для разных изменений" будут постоянно приводить к появлению новых вещей, а новые вещи требуют имён. Придумывать же имена, как известно, это вторая сложная проблема в IT (первая — инвалидация кеша), и она сложна потому, что придуманное название определяет свойства и ожидания от объекта. И вам придётся каждый раз мучительно придумывать имена. Каждая ошибка — кусок кривизны в архитектуре. Если раньше изменения были "потому что надо поменять", то теперь изменения будут, потому что "так нужно для реализации свойств сепульки". Я старался избегать анекдотических примеров (из жизни), но всё-таки приведу. У меня в одном проекте ушло три недели на то, чтобы придумать имя "системная конфигурация" (для описания той части изменений, которые затрагивают настройки серверов и требуют использования ansible, как противоположность "программной конфигурации", для описания той части, которая не требует вмешательства ансибла). Идея оказалась разумной и помогла разделить невозможно переплетённый комок зависимостей "надо поменять на сервере А но только после того, как пользователь поменяет в интерфейсе Б, но если пользователь поменяет В, то нам А трогать не надо, а если пользователь поменяет Е, то поменяется В и Б, так что нам надо как-то одновременно поменять и конфигурацию сервера, и ту часть, которая ансиблом не конфигурируется". Уф… Давно забытый ужас. Который надо было прочувствовать, продумать и найти имя для отдельной сущности внутри него.
Поскольку кнопки для смены конфига на сервере жмутся всё меньше, а раздумий об абстрактном всё больше, то жизнь постепенно переползает с ssh user@server на git commit .
Это означает, что вслед за системой управления конфигурациями приходит многое из жизни программистов. Структура кода (кода!!), тесты, выразительность и понятность, code review, готовность и устойчивость кода (кода!!) к неожиданным изменениям ТЗ, само ТЗ начинает так или иначе появляться. Появляются issue, которые не "чинить сейчас", а "придумать как устранить", появляется техдолг (сейчас нафигачили, надо переписать), появляется бэклог, появляются well-known bugs. Пример: . да, да, мы знаем, что сейчас наша конфигурация неправильно настраивает опции кеширования для дисков, но для внесения изменений нам надо сначала переписать кусок, отвечающий за классификацию блочных устройств. Это при том, что нормальный админ уже давно бы сделал hdparm -W 0 /dev/sda на 400 серверах в цикле. Возможно, к 300 серверу он бы понял, что sda иногда — это виртуальный cd-rom и надо на каждом сервере проверять кому атрибут выставляется. но это уже другая история.
Жизнь админа становится всё меньше похожа на жизнь админа. Профессия разделяется на тех, кто пишет конфигурацию и тех, кто её сопровождает (т.е. остаётся на фронтире, наедине с сервером). Таких иногда называют SRE, и в зависимости от критичности проекта в каждый момент времени, это может быть как очень крутая и важная профессия, так и "апгрейженный саппорт".
Если я вас чуть-чуть мотивировал, но вы не знаете, с чего начать, то начните с поиска системы управления конфигурациями, которая вам по душе. Это Ansible, cfengine, Chef, Juju, Puppet, SaltStack, Quattor, etc. Вероятнее всего, список не полон. Ни одно из этих решений не является хорошим (на мой взгляд), но это лучшее, из того, что у нас есть. Выбор такой системы частично нужно основывать на известных языках программирования (это моё IMHO), ощущении от синтаксиса и жизнеспособности проекта.
После выбора ПО, не стоит бросаться с головой. Читать умные книги по такой системе надо, играться тоже можно до любого уровня сложности, но внедрять стоит очень ограниченно, не теряя контроля над ситуацией. Это означает, что начинать надо с простой автоматизации длительных действий (перепишите свой любимый скрипт деплоя на языке системы управления конфигурацией), попробуйте в него записать хотя бы часть того, что делаете руками.
Одним из интереснейших лайфхаков с системами управления конфигурациями, я считаю лабораторное применение. Когда исследуется новое ПО, то конфигурация этого ПО силами системы управления конфигурациями позволяет "попробовать снова" (если не ясно, делает ли ПО сайд-эффекты по серверу).
Заодно, описание для робота "что делать" отлично подходит на роль эскизного проекта внедрения. Одно время я отлаживал corosync, который не хотел работать в сети с лимитом на unknown unicast/multicast. В ходе отладки мне пришлось несколько десятков раз переподнимать кластер. Когда это делалось ansible'ом, "несколько десятков раз" не стали подвигом, а пришли к чему-то уровня "перезапустить лабораторию".
Ежедневное применение систем управления конфигурациями требует перестройки самых базовых инстинктов работы с серверами, но взамен очень неприятной learning curve даёт на руки не только инструмент для повышения эффективности труда, но и смену модели поведения и мышления на более эффективную. Это очень тяжёлый шаг, но шаг, который нужно обязательно сделать.
Читайте также: