Аркадий Шейн обобщил (http://tigro.info/blog/index.php?id=431) опыт накопленный при создании ресурса mirror.yandex.ru (http://mirror.yandex.ru), указал на подводные камни и привел советы по оптимизации.URL: http://tigro.info/blog/index.php?id=431
Новость: https://www.opennet.ru/opennews/art.shtml?num=13790
Э, погодите, у него были подземные камни!
Интересно какие разумные объяснения перехода с XFS на ReiserFS, вроде как на всех форумах только и слышиться: пора линять с этого Reiser-a, XFS это супер гуд, а здесь вроде люди не глупы ...
>Интересно какие разумные объяснения перехода с XFS на ReiserFS, вроде как на
>всех форумах только и слышиться: пора линять с этого Reiser-a, XFS
>это супер гуд, а здесь вроде люди не глупы ...Полноте, если человек использует федору и одиночные SATA-диски для нагрузки, то совершенно очевидно, что времени набить шишек более долгосрочного плана у него ещё попросту не было.
Это не проблема, но для десятилетнего стажа странно. Ещё понятно, если бы слакварь, но уж с хранением-то данных можно было разобраться, в яндексе есть у кого спросить -- там несколько человек из ALT Linux Team как минимум :)
A я думал ты расскажешь что делает XFS с данными при падении электричества, как недавно было на squirrel ;)
>A я думал ты расскажешь что делает XFS с данными при падении
>электричества, как недавно было на squirrel ;)Может, тебе рассказать, как рассыпаются в таких условиях железные рейды с BBU? :)
Или даже лучше про кашу на рейзере вместо ноликов на xfs? :)...Про плохости XFS я и так рассказываю на каждом углу, когда советую там, где предположительно на _это_ наступить можно.
Уф, 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 (--""--).
Коммент пограмотнее статейки :)Небольшое дополнение - во FreeBSD mount --bind отсутствует, поэтому там можно использовать mount_nullfs =)
Про скрипты - конечно, для такого уровня.....полупозор, имхо, параметризовывать однозначно. Удобнее же :)
>Небольшое дополнение - во FreeBSD mount --bind отсутствует, поэтому там можно использовать
>mount_nullfs =)Слышал звон, что в nullfs фрёвой какие-то баги с утечкой ресурсов ядра были, некоторое время назад в багзилле висел баг в nullfs с довольно бородатой историей. Не знаете подробностей?
> и при возможности организовать вынос журналов на отдельный шпиндельНе подумал, что можно прочесть по-разному; на всякий -- речь о журналах файловых систем, а не логах vsftpd :) Хотя логи (запись) тоже может помочь сложить отдельно от чтения, но тут больше может помочь noatime и вообще -- сам ещё не сравнивал и коллеги тоже не отзывались.
Пост в перемешку со статьей дал довольно полную картину о том как делать, что делать и зачем делать.
Большущее спасибо.
Большущее не за что -- главное было тему поднять :)Вот ещё кусок, пусть будет до кучи...
> Наконец-то Михаил Шигорин написал что-то по делу.Посмотрел "Michael Shigorin site:tigro.info" -- буду признателен за ссылку, когда я здесь написал что-то не по делу.
Наверное, стоит добавить, что времени на тех, по кому видно, что дела не будет -- стараюсь просто не тратить. Исключение -- случай "для архива", когда сказана грубая ложь по небезразличному мне вопросу и решаю показать именно факт лжи, и заскоки (тоже ж человек).
Так что предлагаю конструктивную критику считать комплиментом -- естественно, на полностью симметричных условиях: я уже считаю.
----------------------------------------------
> обвинений
Аркадий, да какие обвинения :-) Я лично благодарен Вам лично и Яндексу как лавке, что такой ресурс есть. Вон ASP12 от вас зеркалил по совету Лёни, поскольку ихний ftp ближе к лежал тогда.
> за много лет, я от ALT Linux тоже ждал большего!
Я тоже; да и сейчас жду, но до чего дотягиваюсь -- то делаю сам. Отличие от ASP, по крайней мере -- получается сразу добавлять в unstable и из него (или бэкпортами) -- в дистрибутивы, а не жить левым репозиторием, как бедный родственник, со всеми вытекающими проблемами.
> Вообще я хотел написать статейку про финты с rsync
А, вот оно как. Это получилось -- мне тоже именно про rsync нашлось что почерпнуть :)
> Про это дело практически ничего Вы и не сказали
Потому что оно и было изложено наиболее компетентно. Собственно, перечитывая перед постингом -- смягчил там некоторые "наезды", поскольку вспомнил, что Вы ж описывали зацепление за ls-lR и другие "маячки", чтоб те каждые две минуты не дерево бросаться сканировать, а один файлик (но замечание про достаточность часа остаётся в силе, коннекты тоже не бесплатные для той стороны).
> Да у нас был 5-й рейд и XFS. 5-й рейд не подошёл
Угу, он быстрее проседает под записью.
> а до 10-ки мы решили не доходить.
Слишком большая потеря пространства?
Кстати, когда будете заменять вылетевшие одиночные диски -- хорошо бы по возможности не забывать сперва восстанавливать на них подзеркала в точности так, как были на момент отказа, и только потом --bind или там правами давать их тащить дальше.
Альтам (и мне заодно) как-то вдвигали фитиль за то, что они без предупреждения убрали с ftp апдейты для 2.2 (который был уже древний и неподдерживаемый, но тем не менее), у меня они успели удалиться rsync'ом, а потом залили назад из загашника как раз вот pilot@. До сих пор лежат, и до сих пор мне rsync (ну, crond) каждую ночь письма шлёт, что permission на удаление denied, а что-либо делать -- лень. :)
> Почему заменили XFS на ReiserFS? Не могу сказать, интуиция.
Можете поверить, можете проверить, но от моей интуиции Вашей привет...
Проверять (подкреплять, воспитывать, нужное, подчеркнуть) интуицию помогают bonnie++ с возрастающим числом потоков и тест вида "десять читают, один пишет" (как для зеркала).
> К тому же о наличии или отсутствии рейда решения принимали много людей
Так и предполагал, но советы-то давали Вы. Собственно, существенная часть иронического или отрицательного отношения в комментарии -- именно поэтому. Если хотите, можете его пересмотреть в таком свете: поправки ли это к советам? Делают ли они его таким, за какой не стыдно?
Мне, понимаете, бывает стыдно за свои советы -- поэтому очень хочется, чтобы тем людям, с которыми так вот сталкиваемся, стыдно за уже пройденные глупости или недодуманности бывало пореже. Особенно если они или хорошие дела делают, или хотя бы большую половину всё правильно сказали.
> Файлопомойкой я называю структуру зеркала.
Стораджа или зеркала? Впрочем, неважно -- плоская структура как раз и есть классика файлопомойки.
> Я отказался от подобных принципов в угоду пользователю.
А, т.е. все дураки, один я дартаньян? Поймите, и на ibiblio, и на heanet сидят не совсем лохи. Просто они уже проходили тот этап, когда "всем хватит корня диска C:".
> Так что я считаю свой подход верным, да и мы не
> зеркалируем все подряд.Мы разделили сторадж (ну, ftp/http/rsync) и "морду" к нему:
ftp://ftp.linux.kiev.ua/pub/
http://www.linux.kiev.ua/ru/download/ (тж. en, ua)При этом на морде есть ссылки на другие серверы в округе, список "основных" подзеркал (с одной стороны, он первый кандидат в протухание -- с другой, тут же ссылки на источник), а также поиск по индексу и лента новостей по категории "FTP" (с RSS).
Не настаиваю, что это лучший вариант -- он делался хоть и с некоторым продумыванием, но без особого планирования. Но надеюсь, что может пригодиться другим организаторам зеркал, особенно по регионам около LUG'ов.
> По поводу кешей, частей. Если держать, то все.
Что ж, тоже выбор.
> И финтить только если мы не справляемся.
Думаю, heanet тоже справлялись и возможности у них ну никак не меньше. Просто они -- куда мощнее зеркало и популярнее. Вот и кэши.
> Мы справляемся, до этого финтили.
Мы финтим не только потому, что диски покупаются на деньги из задних карманов джинсов пары-тройки человек, а и потому, что не видим смысла зеркалить всякий ненужный древний хлам, который апстрим считает нужным держать на ftp.
Есть и обратный пример -- зеркало ALT исторически у нас местами даже полнее оригинала. Это тоже выбор, в данном разе мой.
В остальном же для нас лучше работает, когда подзеркалами занимаются те, кто заметит проблемы с ними в силу того, что сами же и пользуются (протухло/не обновляется/рассыпалось, да что угодно бывало). Люди меняются, поддерживаемость подзеркал -- тоже, но в общем мне кажется, что такая модель более живучая на выходе, поскольку кому надо, те и делают. Хотя баланс меняется со временем и железом, конечно.
Исошки разве что зачастую сам таскаю, благо несложно.
Сумма: вспомните это, когда диски начнут помирать. Я ж такой въедливый ровно потому, что "плавали, знаем" (правда, помирать не давали). Подход "а мы и так справимся" стоит на данный момент пары десятков гигабайт оперативки и SCSI/SAS/FC-массива, бишь изрядно большей грубой силы на тот же результат на выходе.
> noatime – ага используем, но об это я и не писал.
Очень зря не писали, это ж мегахинт :-)
> думаю, что и с Apache мы бы сейчас потянули, но проверять сейчас не хочется.
Ещё бы... такого и не советовал.
> -W – это спорный вопрос
Да, конечно. Просто было бы здорово сразу такие метить -- "мы подумали и решили". И если выбор был сложен, может иметь смысл озвучить обдуманную альтернативу, раз она настолько неплоха.
(NB: это не _требование_, а опять же пожелание/предложение)
> Это все придирки не по делу.
(пожав плечами) Ну как хотите.
> Пределы на количество соединений? Сейчас unlimit!
Завалить, что ли, в порядке лабораторной... :) Что, и предел на LA не стоит? Соточку хотите? :)
(начинать бороться с [невольным] DoS стоит с лимита соединений с одного IP, ну и помогает readahead, см. /sys/block и hdparm)
> mirror.yandex.ua? Мы и так полу Украина.
Эт была провокация :) хотя в общем-то небезосновательная, но это отдельный вопрос.
> В общем спасибо за обсуждение! Я думаю мы оба чему-то научились.
И Вам спасибо; мне тоже так кажется.
Опять же отличный повод вышел свои соображения из головы вытряхнуть на клавиатуру -- мож и мне где расскажут, что к чему и где будут проблемы, которые я ещё не вижу. Толку-то с них в голове.
Давайте мож через полгода-год провентилируем тему ещё раз да набросаем какое неформальное Mirror-Setup HOWTO с оглядкой на свою конкретику? Есть мнение, что в России вопросы трансконтинентальной связи будут закрываться дольше, чем в Украине (масштабы другие), а вот востребованность линукса вне уже накрытых мегаполисов -- будет расти уже быстрей.
Проблемно зеркала работают:Determining fastest mirrors
* extras: mirror.yandex.ru * updates: mirror.yandex.ru * base: mirror.yandex.ru * addons: mirror.yandex.ru
Reading repository metadata in from local files
http://mirror.yandex.ru/centos/5.2/extras/i386/repodata/prim...: [Errno 12] Timeout:
Trying other mirror.Причем это не только с CentOS, браузер тоже периодически вываливается по таймауту. Нахожусь в Екатеринбурге.
Получаются обломы, дистры определяют как самый быстрый mirror.yandex.ru а потом ждут по полчаса соединения и в итоге не могут соединиться.
>Проблемно зеркала работают:Сегодня на зеркале яндекса какие-то проблемы, судя по всему, с сетью, т.к. пакеты теряются.
Я эту ситуацию наблюдаю уже месяц+, проверяю конечно не каждый день, но каждый раз на это натыкаюсь.
На данный момент, таймаут, по каналу немного косяки есть на последних хопах:
Прыжок RTT Утер./Отпр. % Утер./Отпр. % Адрес
6 6мс 0/ 100 = 0% 0/ 100 = 0% rtcomm-mpls-ekb.yandex.net [213.180.208.30]
0/ 100 = 0% |
7 --- 100/ 100 =100% 100/ 100 =100% rtcomm-mpls-msk2ekb-vlan842.yandex.net [213.180.208.25]
0/ 100 = 0% |
8 --- 100/ 100 =100% 100/ 100 =100% korolev-rtcomm-ekb-vlan842.yandex.net [213.180.208.26]
0/ 100 = 0% |
9 34мс 0/ 100 = 0% 0/ 100 = 0% soyuz-lagg121.yandex.net [87.250.233.99]
0/ 100 = 0% |
10 57мс 0/ 100 = 0% 0/ 100 = 0% toyota-vlan4.yandex.net [213.180.210.181]
0/ 100 = 0% |
11 35мс 0/ 100 = 0% 0/ 100 = 0% pontiac-vlan601.yandex.net [77.88.16.42]
4/ 100 = 4% |
12 49мс 4/ 100 = 4% 0/ 100 = 0% dispenser.yandex.net [77.88.19.74]