На программерской конторе имеется некоторое количество компов c Гентай, включая сервер. Имеется общее хранилище distfiles, которые гента выкачивает (чтобы с каждого компа заново не качать); плюс я ещё иногда со своим ноутом прихожу (с Гентай ;), прихожу, обновляюсь.
Сейчас distfiles и portage расшариваются по сети по nfs3. Хотелось бы что-нибудь пошутрее (а возможно, и по-продвинутее, т.е. чтобы файлики реплицировались на др. компе).
Какую альтернативу посоветуете? Пробовали nfs4 — глюковато (файлы долго удаляет).
Посмотрел в ядре есть ещё afs и coda (ну, не будем же мы по самбе шарить!). Кто какой опыт имеет с этим?
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
ftp?
Общее хранилище distfiles — это… Ммм?
1) Синхронизация с зеркала всех distfiles на сервер.
2) Синхронизация папок с distfiles (/usr/portage/distfiles) на всех компах.
В случае 1 — надо шарить тупо ftp (proftpd например), а на использующих это дело клиентах прописывать локальный ftp в качестве gentoo_mirror.
В случае 2… есть варианты…
a) использовать сетевые папки (NFS, CIFS, …)
б) использовать синхронизацию (RSYNC, …)
в) использовать FTP прокси.
Вариант (а) используется сейчас, как я понял. В принципе — не плохо. Какую технологию использовать конкретно — не имеет большого значения.
Вариант (б) — летит фтопку, введу основательной избыточности (левой нагрузке на сеть).
Вариант (в) может быть вам интересен. Заключается примерно в следующем… (рассказываю на теоретическом уровне, практику осиливаем сами).
Ставим FTP прокси сервер (squid например), вешаем его на нестандартный порт на локальном IP сервера, настраиваем на нем «реверсный режим» на зеркало (например mirror.yandex.ru) (не знаю, умеет ли squid, но по идее — должен) (реверсный режим — при обращении к прокси, он прозрачно передает все команды и п.р. другому, заранее указанному FTP серверу) (пример реверсного прокси для http — nginx). Настраиваем очень долгое кеширование файла, и снимаем ограничение на размер… На клиантах — в качестве gentoo_mirror — указываем IP:port прокси сервера, cron`ом сносим все в папке /usr/portage/distfiles каждую ночь.
Получаем — при установке чего угодно в вашей сети — в первый раз файл качается из инета, копия остается на проксе. При второй и последующих закачках — файл быстренько (почти мгновенно) сливается с прокси сервера.
Так же, если вас беспокоит тот факт, что gentoo по умолчанию не «паралелит» процесс закачки/компиляции — поставьте FEATURES=«parallel-fetch».
Что бы выбрал я…. Если инет безлимный и места на сервере хватает — полную синхронизацию и раздачу по FTP. Если инет стоит немалых денег — вариант с прокси.
А вообще… Может имеет смысл на «интернет входе» в офис поставить прозрачный прокси…? (если инет мегалимитный)
Не совсем.
Используется так:
/usr/portage — шарится по nfs (read only)
/datastore/distfiles — тоже шарится по nfs, но уже rw.
Все клиенты маунтят:
/usr/portage — удалённый portage
и ещё куда-то distfiles
Соответственно на клиентах вообще ни дистфайлы ни портэйдж не хранятся ;), а /usr/portage на сервере обновляется еженощно emerge-delta-websync; правда потом всем клиентам нужно делать emerge --metadata.
-- вроде такая схема тоже минимализирует трафик.
Ещё хотели папку с CCACHE шарить… но я подумал, что при одновременной сборке будет тормозють… или нужна какая-то кэширующая сетевая ФС.
Поэтому
1. Что круче (в данном случае) : cifs или nfs или ещё что-то (секурность не важна, важна скорость)?
2. Хотелось бы какую-нибудь репликацию всего distfiles, причём прозрачная и вкусная, а не тупое копирование cron’ом.
3. С ftp-прокси проблема в том, что это всё нужно как-то чистить. С использованием текущей схемы нет проблем — eclean distfiles.
4. Имеет ли смысл шарить ещё ССACHE? Имхо, локально будет быстрей…
Так. Понял.
Что из этих двух технологий работает быстрей — мне неведомо. Но, я думаю, они работают примерно на одном уровне… Тут нужно просто протестить… И вообще — это два братика…
Если хочется большей производительности — можно подумать на тему «сетевого блочного устройства» (iSCSI, nbd (network block device), GNBD)… Насколько это будет быстрей и п.р. — х.з., но вероятность существует ;).
Вопроса не понял.
Можно попробовать написать скриптик в пару строк, проверяющий наличие ebuild`а в портеже для данного distfile`а… и при отсутствии — осуществляющего удаление distfile`а.
Ситуация такая… CCACHE имеет смысл IMHO только на одной машине, потому что компилить будет в общем случае современный проц быстрее чем выкачивать из сети.
В свое время настраивал несколько серваков на gentoo с кучей VPS (от 30 до 60). Сначала использовал CCACHE — потом отказался, унифицировал USE-флаги теперь использую binpkg. Несмотря на то, что ситуция другая — может имеет смысл подумать/покомбинировать в этом направлении?
P.S. Давно мучает тема шаринга дискового ресурса между несколькими вычислительными единицами (серверами и п.р.)… Причем — с более высоким КПД чем у NFS/CIFS и возможностью «совместного использования» как у NFS/CIFS. В свое время нашел некоторый «список» решений (iSCSI, nbd (network block device), GNBD), но так и не добрался до тестирования/практики.