Современный Linux-сервер: как планировать дисковые ресурсы

Алексей Барабанов

От того, насколько правильно будет учтен и cпрогнозирован рост данных, размещенных на создаваемом сервере, зависит в самом прямом смысле срок «жизни» самого сервера! Но можно не заниматься математическим предсказанием увеличения объема информации в сети, а использовать технологии хранения, допускающие оперативное масштабирование и резервирование.

Большинство из представленных далее положений и рекомендаций прошли многолетнюю проверку практикой. Но тем не менее не надо все изложенное считать жесткой схемой. Это всего лишь одно из мнений. Воспринимите статью как попытку упорядочить подход и поиск общих путей решения проблемы планирования дисковых ресурсов. И задача эта, ранее в эпоху магнитных дисков типа RK для PDP-11 решаемая всегда очень просто и однозначно, а сейчас – уже с привлечением всего разнообразия современных технологий, далее будет лишь эволюционировать в сложности и многообразии подходов. Поэтому эпитет «современный» в названии надо читать как соответствующий настоящему уровню развития. Выберем для работы универсальный дистрибутив, например, SuSE Linux 10.0 выпуска конца 2005 года, который и примем за эталон современности. Далее рассмотрим, что нам сейчас предлагается и какой сложности выбор предстоит сделать каждому при создании нового сервера.

Постановка задачи

Прежде всего зададимся вопросом, в чем цель действий, производимых в процессе разметки дисковых устройств. Нужны ли вообще все эти «страдания молодого Вертера», если каждый дистрибутив, и SuSE в том числе, предлагает в процессе установки выполнить автоматическое разбиение? Как определить критерии оценки правильности решения о типе и способе обустройства дисковых ресурсов сервера? Определим нашу цель так: правильным будет такой способ, который в дальнейшем цикле эксплуатации сервера позволит без привлечения избыточных ресурсов провести как комплекс работ по повышению отказоустойчивости, по увеличению емкости, так и, наконец, провести модернизацию операционной системы или миграцию сервера на иное оборудование. Это, так сказать, программа-максимум. Совсем не обязательно, что все это предстоит. В моей практике много таких серверов, которые работают до полного износа оборудования (более 5 лет) без каких-либо модернизаций. Но целью выбора оптимальной структуры дисковой системы поставим именно удовлетворение перечисленных критериев. Прокомментируем их.

Во-первых, что такое цикл эксплуатации сервера. Будем считать таковым срок от введения сервера в строй до его демонтажа, или до модернизации (upgrade) операционной системы или аппаратного обеспечения. Первое понятно, второе обосную. Поскольку все, что далее описывается, относится к области профессиональной деятельности, то всякая работа имеет денежный эквивалент, и экономия средств принимается одним из главных критериев любой профессиональной деятельности. Так и здесь. Модернизация производится не из-за вдруг возникшей тяги системного администратора к новизне, а потому что в старой версии или на старом оборудовании сервер далее работать не может. То есть несоответствие стало столь существенным, что решено потратить средства на модернизацию. Ну а если так, то существенные изменения позволяют считать сервер после модернизации уже другим и соответственно этому начать отсчет нового цикла, тем более что и операционная система, и оборудование сервера сами по себе имеют жизненный цикл, который нецелесообразно превышать.

Во-вторых, зачем нужно увеличение отказоустойчивости? Почему при вводе сервера в строй это не считали необходимым, а вот со временем вдруг озаботились? Будем считать, что с увеличением срока эксплуатации возрастает объем внутренних данных сервера и тем самым увеличивается его информационная и абсолютная ценность.

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

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

Перечислив положительные качества, не забудем упомянуть и отрицательные – те, что обозначены в формулировке как «избыточные ресурсы». Избыточным будем считать все, что привлекается лишь для совершения самой операции увеличения, улучшения или модернизации. Например, если для увеличения дискового пространства потребуется не только подключить новый диск, но еще и придется выкинуть старый, то такой нескомпенсированный обмен надо считать «избыточным ресурсом». Также избыточными будем считать все траты на подобные операции. Например, если модификацию можно осуществить без перерыва в работе, то это идеал, в противном случае – нет. А на практике там, где обсуждаются не идеальные, но реальные условия, чем меньше ресурсов потребуется для проведения операции, тем лучше.

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

Теперь, когда цель ясна и определена, обсудим сами устройства хранения и те технологии, что предлагаются на выбор «из коробки» при сегодняшнем уровне развития в SuSE Linux 10.0.