Алгоритм создания зеркал (website mirror)

Описание

В настоящем руководстве представлены материалы по созданию системы зеркал различного программного обеспечения. Описаны основные трудности при создании системы зеркал, показаны пути их преодоления. Для системных администраторов и SEO-специалистов. Создание системы зеркал программных продуктов включает следующие этапы:

1. Создание адреса
2. Выделение требуемого дискового пространства
3. Создание зеркал
4. Добавление зеркал в список зеркал (mirrors list).

1. Введение

Целью создания системы зеркал является получение ссылок со страниц сайтов, обладающих высоким значением PR.
Как правило, широко известные сайты разработчиков программного обеспечения обладают достаточно высоким значением PR. При этом, с целью уменьшения нагрузки на сервер, с которого осуществляется загрузка программного обеспечения конечными пользователями, они приветствуют создание зеркал своего программного продукта ( при малых объемах — полного зеркала сайта, при больших объемах — репозиториев файлов). Не углубляясь в исторические причины этого явления, отметим только одно — в случае создания зеркала программного продукта каким-либо сайтом, его вносят в список зеркал ( mirrors list ) на сайте — источнике. Тем самым автоматически повышая его PR.
Целью выпуска документа является представление проведенных работ с целью анализа результатов, определения проблемных моментов создания системы зеркал, разработки предложений по их преодолению.
В документе отражены основные результаты работ, проведенных на протяжении четырех месяцев — сентябрь — декабрь 2011 г.

2. Создание адреса

2.1. Создание зеркала для собственных нужд

Если зеркало создается для собственных нужд, никаких проблем нет – создаете обычный сайт, в котором каждое зеркало размещаете в собственной директории.

2.2. Создание зеркала для партнера

Наиболее простой способ создание зеркала для партнера заключается в создании записи CNAME с указанием в качестве адреса зеркала партнера адреса собственного зеркала.
Например:
Имеем: сайт партнера domain.com и собственный сайт fatcow.com.
Создаем: зеркало mirrors.domain.com на базе нашего сайта fatcow.com.
Для настройки зеркала партнер должен прописать на своем DNS-сервере запись:
mirrors.domain.com CNAME fatcow.com
Далее, в настройках своего web-сервера необходимо создать запись для сайта mirrors.partner.com с указанием в качестве корневого каталога корневой каталог fatcow.com.
При необходимости аналогично можно создавать зеркала в виде отдельных поддоменов, однако в этом случае для каждого поддомена необходимо прописывать отдельную запись CNAME, например:
apache.domain.com CNAME apache.fatcow.com
putty.domain.com CNAME putty.fatcow.com
Очевидно, что для каждой записи на своем сервере необходимо произвести соответствующие настройки собственного web-сервера.

3. Требуемое дисковое пространство

3.1. Общие соображения

Одним из ключевых вопросов создания системы зеркал является достаточное количество дискового пространства для их размещения. Если вы имеете полную информацию о требуемом объеме дискового пространства, этот вопрос легко закрывается. Но разве можно иметь представление об объеме жесткого диска, перед тем как реально начнете синхронизировать первый проект?
К сожалению, в нашем случае было несколько иначе. В связи с отсутствием опыта (и своего, и чужого) в данной области, создание системы зеркал было начато при первоначальном весьма скромном объеме дискового пространства 250 Gb. Очень быстро пришло понимание, что этого явно недостаточно и дисковое пространство было расширено до 500 Gb путем подключения второго диска аналогичного (250 Gb) объема. При том, что OS Linux с использованием LVM (Linux Volume Manager) позволяет достаточно безболезненно произвести подобную операцию, некоторое время наблюдались случаи сбоев в работе (вплоть до полной остановки сервера), связанные, скорее всего, с нестабильной работой файловой системы.
Далее, реальные объемы размещаемых данных достаточно велики. Общие объемы репозиториев некоторых операционных систем — Linux, различные версии BSD, включающие себя различные версии OS ( в том числе устаревшие и неподдерживаемые, бинарные и исходные коды, пакеты программного обеспечения и т.д. и т.п.) легко достигают сотен и более Gb. В связи с этим пришлось еще раз откорректировать свое понимание необходимых объемов.
ТАБЛИЦА 1

График увеличения объема дискового пространства

В начале декабря было принято решение увеличить объем не менее чем до 1TB (стоимость выделенного сервера увеличивается на $25/мес). При этом однозначно понималось, что данные должны быть перенесены на один диск такого объема, поскольку подключение, например, еще одного диска объемом 500 Gb резко снижает надежность сервера — наличие трех работающих дисков в три раза повышает вероятность сбоев. Также необходимо принимать во внимание возможность дальнейшего расширения дискового пространства.
Сразу отметим, что использование RAID не планировалось — в случае потери данных они могут быть восстановлены в течение 1-3 дней ( для зеркал с большими объемами данных) с сайтов-источников. Скорость восстановления зависит от полосы пропускания каналов и загрузки сервера — источника и нашего сервера. Это позволяет уменьшить совокупную стоимость оборудования. Однако при этом необходимо уделить большое внимание сохранности данных собственных сервисов.
По наличию на складе хостера была достигнута договоренность об установке диска объемом 2TB (при этом стоимость выделенного сервера увеличивается на $35/мес), что в некоторой степени сняло моральное напряжение в смысле вопроса — на сколько хватит 1TB? Однако далее процесс переноса данных на диск объемом 2TB столкнулся со значительными трудностями ( возможно, это связано с недостаточной квалификацией нашего хостера ). Первоначальное подключение диска 2TB с перенесенными данными закончилось неудачей — как пояснил хостер, CentOS 5.6, установленная на нашем сервере, не может обеспечить загрузку с диска объемом 2TB. После чего на этот диск была установлена CentOS 6.1 и перенесены данные. Учитывая, что ряд сервисов был настроен для работы с CentOS 5.6, потребовалось осуществить ряд работ после установки системы. В частности:

• восстановление phpMyAdmin и его взаимодействие с ISP menаger;
• восстановление работоспособности ISP menаger при редактировании файлов;
• восстановление заданий cron;
• восстановление настроек бэкапа;
• восстановление системы мониторинга.

Все эти периодические подключения-отключения дисков, конечно, дестабилизируют работу и в конечном счете, снижают производительность и могут затянуться на несколько недель. Поэтому, в качестве рекомендации хорошей идеей можно считать начальным объемом дискового пространства для размещения системы зеркал 1TB, что позволит в дальнейшем избежать ненужных неприятностей, подобных вышеуказанным.
Если вас (как вам кажется) не беспокоит объем дискового пространства, этот пункт можно пропустить. Однако в реальной жизни безграничных ресурсов не бывает и мы настоятельно рекомендуем перед началом установки зеркала произвести оценку его объема.
В первую очередь поищите на сайте владельца продукта указание на объем дискового пространства, необходимый для создания зеркала. Эти сведения находятся в инструкции по установке зеркала. Если инструкция отсутствует или эти данные не приведены, оценку требуемого объема придется произвести самому.
Наиболее простой путь – постепенная закачка по FTP с сайта-источника программного обеспечения ( ПО ), планируемого к установке в качестве зеркала. В этом случае вы имеете возможность постепенного ( по директориям ) создания зеркала с контролем объема.
В ряде случаев возможна первоначальная закачка с использованием rsync, запустив его из командной строки. Однако, учитывая достаточно большой объем зеркал, необходимо периодически контролировать занятое дисковое пространство, чтобы в случае необходимости прервать процесс закачки.
Будьте внимательны – первоначальная закачка зеркала может идти боле суток! Идеальным решением в данном случае является наличие системы мониторинга сервера.
Вообще-то говоря, существует еще два варианта оценки объема зеркала, менее затратных с точки зрения временных потерь и угрозы переполнения диска:
Первый — получить информацию от владельца данных, что в ряде случаев не всегда приемлемо.
Второй вариант — использовать утилиту, позволяющую с использованием какого-либо протокола ( HTTP, FTP ) произвести оценку ( подсчет ) суммарного объема всех файлов зеркала без их загрузки. К сожалению, никаких готовых программных решений мы не нашли, поэтому пришлось разработать скрипт на php для оценик объема зеркал на удаленном FTP-сервере. Его использование позволило в значительной мере сократить временные затраты при установке зеркал.
Ниже приведен исходный код скрипта.
<?php
//===============================================================
// Directory size
// #php path_to_script host_name directory
//
//===============================================================
function ftp_dir_size($connect, $dir)
{
$dir_size=0;
$file_list = ftp_rawlist($connect, $dir);
//print_r ($file_list);
// get directory list
foreach($file_list as $file)
{ $dim=explode(' ',$file);
if (count($dim)>3)
{ //echo "----------------------------n";
list($attr,$bloks,$group,$user,$size,$month,$day,$year,$f_name)
= preg_split("/[s]+/", $file);
$pr_dir=substr($attr, 0, 1);
//echo $attr."n";
//echo $pr_dir."n";
//echo $f_name."n";
//echo $size."n";

if (substr($file, 0, 1) != '.')
{ // directory
if($pr_dir == 'd')
{ $t_dir=$dir."/".$f_name."/";
$dir_size=$dir_size+ftp_dir_size($connect, $t_dir);
}
// file
if($pr_dir == '-')
{ echo "***".$f_name."-".$size."n";
$dir_size=$dir_size+$size;
}
}

}
}
return $dir_size;
}
//===============================================================
set_time_limit(3600);
$host=$argv[1];
$dir=$argv[2];
echo $host."n";
echo $dir."n";
$user = «anonymous»;
$password = "";
$connect=ftp_connect($host);
if ($connect)
{ $login = ftp_login($connect, $user, $password);
if ($login)
{ if (ftp_chdir($connect, $dir))
{ $dir=ftp_pwd($connect);
echo «new directory-».$dir."n";
}
else { echo «Cannot change directoryn»; }
$size=ftp_dir_size($connect, $dir);
// print directory size
echo "nDirectory size=".$size;
}
ftp_close($connect);
}
else { echo «Not connect with ».$host; }
?>
Для оценки занятого зеркалами на собственном сервере дискового пространства удобно использовать утилиту ncdu, которая позволяет выводить сводку по каждой директории:

Результаты рекомендуется свести в таблицу, что позволит оценить динамику изменения ( или стабильности ) каждого из зеркал.

4. Создание зеркала

4.1. Создание зеркала на основе rsync

Как правило, наиболее распространенным способом создания зеркала является синхронизация с rsync-сервера сайта-источника с использованием одноименной утилиты rsync. Если на сайте владельца ПО имеется инструкция по настройке rsync, проблем вообще не возникает. Например, на сайте http://cran.r-project.org/ имеется достаточно подробная инструкция по настройке зеркала. В части, касающейся настройки rsync имеем:

В данной инструкции приведены, как минимум, два интересующих нас момента:

• самый главный — адрес для закачки данных — cran.r-project.org::CRAN;
• частота обновления зеркала- по крайней мере два раза в неделю, лучше — раз в 1-2 дня.

В соответствии с этими указаниями создаем задание в cron для запуска rsync по имеющейся инструкции и на этом процесс завершен. Рекомендуется протоколировать работу rsync, что позволит выяснить, в случае необходимости, причины невозможности синхронизации.
Полная документация по rsync находится на сайте http://rsync.samba.org/. В разделе документации (http://rsync.samba.org/documentation.html) приведены все возможные случаи использования rsync.
Отметим один важный момент. В случае недостатка дискового пространства вместо директивы --delete-after предпочтительно использовать директиву --delete. В случае использование директивы --delete-after производится сначала закачка файлов, а после этого удаление отсутствующих на сайте — источнике. При этом зеркало максимально быстро приводится в состояние полного соответствия оригиналу, что может быть важно для часто изменяющихся зеркал, таких как mozilla. В случае использования директивы --delete сначала производиться удаление уже отсутствующих на сайте — источнике файлов, после чего производиться закачка новых. Этот режим рекомендуется использовать для достаточно объемных зеркал (CentOS, DragonflyBSD).
Все остальные настройки — в зависимости от ваших предпочтений, если они не противоречат инструкции.
В ряде случаев на сайте владельца ПО нет данных по настройке зеркала ( gcc.gnu.org ):

В этом случае установка зеркала невозможна без предварительного контакта с владельцем ПО (подробнее — в разделе 4).

4.2. Создание зеркала на основе FTP

Более редким случаем является создание зеркала на основе FTP. В общем-то, последовательность настройки тут та же самая, как описано выше, за исключением того, что для синхронизации вместо rsync необходимо использовать какой-либо ftp-клиент. Обратите внимание, что очень хорошо зарекомендовавшая себя утилита wget (как, впрочем, и многие другие) для нашего случая не подходит — кроме закачки файлов нам необходимо обеспечить удаление отсутствующих на сайте — источнике. Пожалуй, лучшим выбором будет использование утилиты lftp ( lftp.yar.ru/ ) в режиме зеркала.
Порядок настройки утилиты lftp ( в том числе при работе в режиме зеркала ) можно прочитать на сайте разработчика (http://lftp.yar.ru/lftp-man.html).

4.3. Контроль дискового пространства

После того, как зеркала установлены, рекомендуется на сервере установить систему мониторинга доступного дискового пространства с оповещением (e-mail, sms), что не позволит привести к остановке сервера в случае полного заполнения дискового пространства.
Очевидно, что вопросу контроля дискового пространства надо при наличии большого количества зеркал надо уделять достаточно серьезное внимание. В отличие от собственного ПО, любое зеркало может достаточно резко увеличить свой объем, например, в случае выхода новой версии. Для автоматического контроля дискового пространства рекомендуется использовать систему мониторинга, например, Munin (http://munin-monitoring.org/). Это достаточно легко настраиваемая, расширяемая система. Наряду с возможностью визуального контроля параметров с использованием web-интерфейса, она позволяет создавать оповещения по e-mail при достижении контролируемым параметром некоторого порогового значения.
В ряде случаев возможно уменьшить объем зеркала за счет синхронизации только стабильных версий ПО. Очевидно, что это должно быть согласовано в владельцем ПО. В этом случае настройка зеркала становиться сложнее, однако выигрыш очевиден.

5. Добавление зеркала в список зеркал

Добавление зеркала в в список зеркал на сайте владельца продукта – с моей точки зрения, самая сложная процедура во всей технологии организации зеркал. Связано это с тем, что все ранее описанные операции вы можете выполнить собственными силами. Для добавление зеркала в список зеркал, понятно, вам необходимо добиться согласия владельца сайта.

5.1. Вариант 1

Наиболее тривиальный случай – в инструкции по установке зеркал четко написано примерно такое “установите зеркало, напишите нам на адрес mirrors@example.com и мы добавим вас в свой список зеркал”.
Такое было, например, при установке зеркал:

• ImageMagick (http://www.imagemagick.org/);
• KDE (http://www.kde.org)
• Dragonfly BSD (http://www.dragonflybsd.org/)

Однако даже в этом случае успех не гарантирован сразу. Возможно, письмо не дошло с первого раза. Возможно, люди собрались сделать, но не успели сразу, а потом забылось. Да мало ли еще причин. Возможны и просто задержки с ответом.
Приведем для примера переписку по созданию зеркала для ImageMagick:

• 7.11.2011 было отправлено письмо с запросом о создании зеркала;
• В тот же день пришел ответ:”Ok. When its ready, let us know and we will include it in our mirror web page”;
• 8.11.2011 зеркало было установлено и направлено письмо с просьбой о включении в список зеркал;
• Ответ не был получен, и поэтому 9.11.2011 было направлено повторное письмо о включении в список зеркал;
• и лишь 17.11.2011 был получен ответ:”Done. Look for it on the ImageMagick download page in about 24 hours. Thanks”.
• 18.11.2011 было проверено наличие ссылки в списке зеркал ImageMagick http://www.imagemagick.org/script/download.php и после подтверждения работа была закрыта.

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

5.2. Вариант 2

В ряде случаев в инструкции по установке зеркала написано – «Установите зеркало, пришлите письмо и мы рассмотрим вопрос о вашем включении в список зеркал”. Т.е., в данном случае существует вероятность, что ваше зеркало не будет включено в список зеркал. Тем не менее, закладываться на неудачу не стоит, а стоит спокойно поработать, а далее действовать в соответствии с пунктом 1.

5.3. Вариант 3

В некоторых случаях, для того, чтобы подать запрос на включение в список зеркал, необходима подписка на список рассылки, например, CentOS (http://www.centos.org/). В этом случае ваши запросы по добавлению в список зеркал необходимо добавлять в список рассылки (mailing list).
Пример переписки с CentOS:

• первое письмо отправлено 30.09.2011. Ответ не получен.
• второе письмо отправлено 09.11.2011. Получил ответ, что надо писать в «CentOS-mirror mailing list»;
• проведена регистриция в «CentOS-mirror mailing list», написано 17.11.2011 сообщение в mailing list. Ответ не получен;
• 19.11.2011 написан еще один запрос и 21.11.2011 получил ответ, что зеркало добавлено.

5.4. Текст письма

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

• название организации;
• адрес сайта;
• имя и адрес электронной почты администратора сайта, на котором размещены зеркала;
• географическое размещение сервера (это может быть важно)- страна, город;
• IP-адрес сервера;
• протокол, используемый для скачивания с созданного зеркала (HTTP,FTP) и адрес, например, http://fatcow.com/apache/, ftp://ftp.fatcow.com/apache/ ;
• максимальная скорость подключения к вашему серверу.

Перед отправкой письма еще раз прочитайте инструкцию по установке зеркала (если она имеется). В некоторых случаях владельцы продукта просят указать, например, максимальное количество подключений к вашему серверу. Либо количество запусков процедуры синхронизации – как правило, достаточно синхронизировать один раз в сутки, но иногда просят два раза в сутки. Обязательно дополните текст вашего письма этими данными.

5.5. Подпись и адрес

Подпись к письму – имя, должность, адрес e-mail. Должность: идеально – администратор сайта. В этом случае адрес электронной почты имеет значение! Желателен адрес, домен которого совпадает с доменом зеркала. Или, как общепринятое исключение из правил – почта на GMail. Наличие почты на GMail для администратора сервера – нормальное явление.
Ниже — скриншот реального письма ( использовано при установке зеркала CentOS)

Скриншот реального письма — использовано при установке зеркала ImageMagick

6. Раздача зеркал

Учитывая, что, как правило, в составе программного обеспечения практически любого сервера имеется web-сервер, мы уже имеем возможность организовать раздачу наших зеркал с использованием протокола HTTP.
Тем не менее, мы настоятельно рекомендуем произвести соответствующую настройку FTP-сервера для раздачи зеркал по протоколу FTP. В этом случае, при незначительных затратах (установка и настройка FTP-сервера) мы получаем выигрыш как минимум по трем пунктам;

• мы получаем два адреса в списке зеркал сайта — источника;
• снижается на нагрузка на web-сервер (который может быть использован для внутренних целей) за счет перевода части исходящего трафика на FTP-протокол:
• увеличивается авторитетность нашего сайта как способного организовать полнофункциональное зеркало, что повышает вероятность его внесения с список зеркал.

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

7. Организация работ

Организация системы зеркал — достаточно длительная работа. Установка одного зеркала с учетом переписки может длиться неделями ( под установкой мы понимаем достижение конечной цели — внесение зеркала в список зеркал на сайте — источнике). А уж тем более создание системы превращается в процесс, который может растянуться на месяцы.
При этом работы на собственном сервере должны быть согласованы с процессом переписки. При этом создание зеркал, как правило, производится, одновременно для нескольких сайтов — источников. В связи с этим совсем не лишним будет систематизировать планирование и контроль выполнения работ (http://is.gd/WeFybI). В этот документ для каждого зеркала должны быть включены, как минимум, следующие данные:

• условное название проекта;
• адрес сайта;
• адрес списка зеркал на сайте;
• адрес страницы с инструкцией по установке зеркала.

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

8. Заключение

На протяжение 4-х месяцев значение PR для домена fatcow.com было поднято с нулевого значения до значения PR=4.
В обработке таблице 1 приведены данные по сайтам, зеркала который размещены и добавлены в списки зеркал.
ТАБЛИЦА 2

Примечание. Q — дисковое пространство, занимаемое зеркалом по состоянию на 15.12.2011.

Суммарный объем занимаемого дискового пространства зеркал, приведенных в таблице 1 — 380Gb.
В последнем столбце таблице приведено соотношение Q/PR — своеобразный показатель качества зеркала. Чем он ниже (конечно, в некоторой степени условно), тем более подходящим является зеркало для наших целей.
Из представленных в таблице результатов следует два вывода;
1. Размещение в качестве зеркала операционных систем — достаточно дорогое удовольствие. Создание зеркал на их основе целесообразно при наличии договоренности ограниченного размещения — например, только стабильных копий продукта.
В качестве примера приведем Dragonfly BSD, полный объем которого составляет примерно 400 GB. Особенно большой объем дискового пространства занимали пакеты ПО ( packeges ) для различных версий. В связи с этим синхронизация ПО была ограничена только последними версиями Dragonfly BSD:

В итоге требуемое дисковое пространство было уменьшено по крайней мере вдвое, до приемлемых 200 GB.
Однако, такого соглашения добиться в каждом случае, скорее всего, не удастся. Поэтому проблема дискового пространства напрямую будет зависеть от поставленных задач подъема PR.
2. В первую очередь к размещению следует планировать общесистемное программное обеспечение, работающее на различных ОС — web-сервера, FTP-сервера (ProFTPd), сервера баз данных (MySQL) и т.д.
Исходя из анализа таблицы 2, нами была проведена корректировка отбора предполагаемых к размещению зеркал. В настоящее время в обработке (в разной степени готовности. так работы приостановлены в связи с заменой диска) находятся зеркала, представленные в таблице 3.
ТАБЛИЦА 3

Очевидно, что значение PR, равное четырем — далеко не конечное.
Основными затратными статьями является:

• необходимость поддержки сервера с достаточно большим объемом дискового пространства.
• оклад серверного администратора по частичной занятости

При этом необходимо учитывать, что одновременно с поддержкой системы зеркал данный сервер используется для других работ, что в целом снижает стоимость поддержки системы зеркал. Суммарные траты в месяц порядка $500.
Перевод с английского яз., источник: webhostinggeeks.com

Автор: gasyoun