Уф, ajax-режим пихает ответы в GET. Мои не влазят :)Также опубликовано на tigro.info и здесь:
http://www.linux.kiev.ua/ru/news/comments/view/3118/
-------------------------------------------
М-да. Единственное полезное из прочитанного -- это про ключик rsync --delay-updates.
Всё остальное... впрочем, ниже.
Вот на всякий копия разведённого там в надежде на полезность графоманства:
-------------------------------------------
Краткий вывод: Аркадий, я ожидал большего как от Вас (вроде не первый год слышу), так и от яндекса (хотя если грести всех...).
Пока это всё описывается как советы человека, который берётся опускать ftp.chg.ru до "файлопомойки", хотя сам делает как раз файлопомойку и при этом допускает элементарные ляпы (по крайней мере судя по советам).
Дружески предлагаю над этими моментами задуматься, как организатор зеркал на ftp.linux.kiev.ua с 2002 года (у нас также содержатся официальные зеркала ftp.altlinux.org и ftp.flightgear.org, поэтому о проблемах с ура-тянущими чуточку тоже знаю).
Ниже по пунктам, благо в общем структура изложения нормальная, но в ряде мест делаются более или менее грубые ошибки (ряд из которых ещё и рекомендуется) -- поскольку считаю, что это от недостатка опыта и избытка самомнения, а не от злонамеренности.
Основные намеченные проблемы -- низкий уровень понимания организации storage, потенциально плохие манеры по части задёргивания апстрима и пропуск одной из критичных частей изложения. Первое склонно "кусаться" на протяжении первой же пары-тройки лет существования ресурса.
--- (сторадж)
> 1.5 Тб дискового пространства (это полка и это всего
> лишь Debian+Fedora)
Hint: необязательно держать полные зеркала -- это обмен ещё несколько более внимательного ознакомления с предметом (времени или опыта) на место/нагрузку/трафик.
Это трейдофф, который стоит упоминания.
> Нужен ли рейд? Мы от него отказались, без него
> все оказалось быстрее
Если дешёвый железный, то однозначно; если дорогой или софтовая единичка-пятёрка-десятка, то совсем не однозначно. Опять же выравнивание нагрузки по шпинделям лучше происходит, когда они работают пачками (и readahead подобран).
Короче говоря, у нас на ftp.linux.kiev.ua отдельные диски -- это пройденный этап, сейчас на одном зеркале используется две четвёрки SATA-дисков в RAID5 каждая, на другом -- аппаратный RAID1 на SCSI.
Если получается обойтись четвёрками, то RAID5 хуже под записью, но лучше по объёму; RAID10 меньше проваливается при записи (необязательно цепляются _все_ диски), но всего двойной объём одного диска (при четырёх).
Если не получается -- может иметь смысл подумать о парах дисков в RAID1 вместо индивидуальных, помимо надёжности, это позволяет читать два потока в две головки, а не в одну.
Рейды надо уметь готовить, особенно RAID5/6; в первую очередь stripe size, но ещё надо знать про raid alignment -- и на аппаратных порой тоже. См. http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID
Суммарно -- тут прослеживается эволюция от одиночных дисков к массивам и к унифицированному стораджу. Я вот уже почти созрел на последнее. Дальше -- NAS с Lustre, как вот у нас тут на кластерах (бишь storage backend/frontend и сервис с фронтэнда/ов).
И объём RAM около дисков/сервисов тоже важен.
В любом случае здесь также целая куча выборов.
Также могу предложить поискать около heanet.ie, они там рассказывали вкратце, как организованы машинки (включая frontend cache с быстрым SCSI для того, что "горячее" -- ведь не весь же архив федоры востребован ежеминутно, правильно?).
> load average на зеркале 100%?
Hint: LA не изменяется в процентах.
> Если вы используете рейд, то вероятно разумно поверх него
> натянуть LVM.
Нет. Это же файлопомойка, тут на каждый собранный рейд осмысленно просто положить файловую систему. LVM будет просто жрать CPU лишний раз и в данном разе ничем не полезен (если растягивать логический том на стопку дисков, получим страйп и вся этажерка дружно сложится при выпадении первого же диска -- Вы долго гоняли конкретно свою модель/партию дисков под нагрузкой? в любом разе не забывайте, что живут они не больше трёх лет с хоть какой-то степенью уверенности).
> Какая должна быть файловая система? Тоже вопрос.
> Сейчас у нас стоит ReiserFS, раньше была XFS.
Интересно, зачем было менять то, что держит большую нагрузку, на то, что справляется лучше исключительно со сканированием каталогов. Наверное, чтоб анноить те серверы, с которых тянете, двухминутными ресканами? Они ж не все такие неопытные и торопливые, чтоб использовать reiserfs.
XFS, кстати, держит _нагрузку_ (а не ресканы) благодаря двум вещам: она extent-based (выделяются области для записи, в пределах которых фрагментация в среднем пониженная) и умеет delayed block allocation, что опять же позволяет оптимизировать размещение информации.
Ещё нельзя забывать про опцию монтирования noatime и при возможности организовать вынос журналов на отдельный шпиндель (возможно, RAID1 из двух WD Raptor или 10/15kRPM SAS) -- это весьма рекомендуется коллегами.
В любом случае выбор ФС -- тоже трейдофф, который стоит упоминания; особенно же мотивация смены файловой системы (любой на любую).
--- (лирика)
> Следует продумать её заранее, чтобы не получилась
> файлопомойка по принципу ftp.chg.ru
Если так "продумать", получится уникальная файлопомойка по принципу mirror.yandex.ru, и только.
> (а также множества других зеркал).
Вы не задумывались о том, что далеко не первый занимаетесь вопросом их организации?
Можно было на том же opennet спросить -- "тут сказали организовать крупное зеркало, мужики, подскажите, какие есть грабли". Да хотя бы рядом найти того же pilot@ или других альтовцев.
---
> Я предлагаю делать так. Создаём каталог, например,
> /storage и в него монтируем либо наши отдельные жёсткие
> диски, либо разделы LVM.
Монтируем мы в него файловые системы. Я лично их рекомендую размещать на рейдах. Очень кратко про них уже упомянул.
Про bind mounts -- всё правильно.
--- (missing)
> О том как настроить Web, FTP и rsync сервера я
> рассказывать не буду
А зря, это важно. И то, что rsync _надо_ чрутить, и то, что симлинками вида ../../../ на соседнюю ФС через чрут мы не перепрыгнем (это надо иметь в виду _заранее_), и о том, какие были выбраны пределы на количество соединений и LA -- это всё для зеркала очень важно.
> скажу только что мы используем Lighttpd и vsftpd.
Ввиду неоднократного наблюдения за последние пару лет восторженного подхвата lighttpd в ALT разными опытными людьми, сменяющегося отвращением после похода в код при наступании на грабли вроде "не раздаёт файлики с плюсом в имени" -- я этой софтине доверяю меньше, чем nginx.
vsftpd -- это гуманизм, да :)
--- (разное)
> rsync -aH --partial --timeout=1800 --delete --delete-after --delay-updates \
> машина_с_которой_зеркалируете::модуль
А где trailing slash?
> /storage/каталог/дистрибутива
И тут?
Почитайте по этой части man rsync, самый надёжный синтаксически способ -- именно dir1/ dir2/
> Ключ --delay-updates
О, вот за это спасибо -- обычно выписывал руками такой временный каталог, когда надо было. Тут уже я ман недочитал :)
--- (mirror netiquette)
> Ключ -W для копирования файлов целиком (есть вероятность,
> что снизится нагрузка)
И заодно увеличится потребление трафика теми, с кого тянете. Для них это _бывает_ проблемой. Хотя здесь действительно tradeoff, для них лишняя нагрузка на CPU и дисковую может быть тоже хуже трафика.
Впрочем, это ничто по сравнению со слишком частыми проверками (чаще раза в час) -- хорошо, что приняли меры против перегрузки апстримов (боюсь, пока принимали -- им было плохо).
--- (разное)
> --exclude=файл
Позволяет указать только одно исключение; синтаксис --exclude 'shell*pattern' позволяет указывать стопку оных. Внимание, пути идут от корня компоненты _без_ "/" или "./" в начале.
> я использую самописные скрипты. Ниже приведён
> один из таких файлов
Параметризовать не пробовали?
> принципом Pull-зеркалирования (это я так назвал)
:)))
---
PS: если хотите, можете предложить сделать mirror.yandex.ua и приезжайте меняться опытом ;-) Хотя надо бы добраться накатать свои заметки на linux.kiev.ua, чтоб было кому за что посыпать голову и мне :-)
PPS: забыл по софту добавить. Могу рекомендовать обратить внимание на:
monit (http://tildeslash.com/monit);
collectd (http://collectd.org/);
iftop ($distro/google);
dstat (--""--).