[ttttt]

Ну просветите меня. Что такого космического умеет нынче гит что спасёт хранилище от сдохших дисков или размажет запись по нескольким серверам?

https://git-scm.com/book/ru/v1/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%B5-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9

[Night_Snake]

2. Проблема, как я понял, - это конфиги, которые ручками правятся. Вот тут их все в репозитории и держите и всей командой в репозитории с ними и работаете (не на свичах!), в общем-то для такого git и задумывался. В этот же репозиторий ложите скрипт деплоя этих конфигов на свичи, с проверкой, что они задеплоились (тут уже зависит от свича, по хорошему он не должен принять кривой конфиг, а вернуть ошибку, так что скрипт должен прерваться и дать ее починить). Если все-таки допустили логическую ошибку или нарвались на баг и что-то поломалось, тут же git'ом откатываетесь и деплоите предыдущую версию, а как разберетесь и деплой будет успешным - протолкнете изменения в апстрим. Влияние ошибки можно уменьшить, если деплоить сначала на тестовые свичи или деплоить только на какие-то пару свичей, погонять немного и потом только на все. Есть еще ньюансы с командной работой, но я думаю тут на них никто не наткнется. В любом случае, коробочных решений тут быть не может - просто плохо понимаете, чего хотите. Не делайте фичи хотелками, поймите проблему и делайте решение проблемы хотелкой.

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

[pppoetest]

Согласен, пока только один имеет доступ к железу, ничего этого не надо, генератор конфигов из шаблонов и никаких гвоздей. Если людей имеющих доступ к сабжу становится чуть более чем дохрена, диффы неоценимая вещь для разбора полётов.

[xcme]

Понятно что диффы нужны, у меня они тоже есть. Мне больше интересно насколько часто это применяется на практике?

Т.е. положение между крайностями "Каждый день подчищаю за кем то" или "Есть дифы, но не пользуюсь". :)

[s.lobanov]

Ну просветите меня. Что такого космического умеет нынче гит что спасёт хранилище от сдохших дисков или размажет запись по нескольким серверам?

 

Прекращайте позориться. Как раз Git проще всего реплицировать по разным серверам и никакого геморроя, даже если один сервер не будет работать длительное время. Даже с классическими БД, где механизм репликации и подтягивания данных после креша уже не первый десяток лет существует и то не всё так гладко

[s.lobanov]

Понятно что диффы нужны, у меня они тоже есть. Мне больше интересно насколько часто это применяется на практике?

Т.е. положение между крайностями "Каждый день подчищаю за кем то" или "Есть дифы, но не пользуюсь". :)

 

Тут два фактора. Первый это регулярность стройки и всяческих переключений, модернизаций и т.д. Второй - это дизайн сети. Если у вас S-Vlan и появляется абонент с "особой" услугой, которая требует отдельный vlan, тут и появляется свистопляска с конфигами, их бэкапом и т.д. Если, к примеру, у вас уже vlan-на-порт на доступе и есть возможность эти же вланы использовать для "особых" услуг, выщепляя их в ядре/на брасе, то в принципе тоже бэкапы доступа не нужны - тупо генератор

[alibek]

Т.е. положение между крайностями "Каждый день подчищаю за кем то" или "Есть дифы, но не пользуюсь". :)

Обычно это не нужно.

Но если что случится, то лучше чтобы они были, чем чтобы их не было.

[sexst]

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

 

- Git легко реплицировать, ага. Он для этого создан, внезапно. Только вот меня как-то ломает сотни гигабайт хранить в несжатом виде. Ну окей, бэкапы закрываем, считаем что реплицируем все на другой сервер и как-то настраиваем фейловер.

- Вопрос про Load balancing все игнорируют. Кроме git over http и внешнего http балансировщика я как-то ничего не вижу, но внезапно http работает, ЕМНИП, только на чтение. Начинаем решать задачу долгим раскуриванием манов и костылями.

- Способ вкрутить все это добро в единую морду саппорта с поиском и плюшками без кучи человекочасов? Внезапно нет.

- Git по производительности в работе с сотнями тысяч мелких конфигов мощно сольет специализированной БД. Поинтересуйтесь у Володина почему git и mercurial в данном случае говно. У меня лично ежедневный бэкап конфигов не успевал всосаться на диск за сутки.

- Продолжаю настаивать что развернуть git с удовлетворением всех имеющихся требований куда геморройнее и дольше.

 

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

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

[ttttt]

- Git легко реплицировать, ага. Он для этого создан, внезапно. Только вот меня как-то ломает сотни гигабайт хранить в несжатом виде. Ну окей, бэкапы закрываем, считаем что реплицируем все на другой сервер и как-то настраиваем фейловер.

- Вопрос про Load balancing все игнорируют. Кроме git over http и внешнего http балансировщика я как-то ничего не вижу, но внезапно http работает, ЕМНИП, только на чтение. Начинаем решать задачу долгим раскуриванием манов и костылями.

Может хватит бредни писать? А то недалекие люди еще почитают и поверят.

Git не нужно ни реплицировать, ни балансировать в принципе. Это все проблемы централизованных систем.

 

- Способ вкрутить все это добро в единую морду саппорта с поиском и плюшками без кучи человекочасов? Внезапно нет.

Не нужно совмещать саппорт с конфигами свичей.

 

- Git по производительности в работе с сотнями тысяч мелких конфигов мощно сольет специализированной БД.

Git прекрасно работает с сотнями тысяч мелких файлов.

 

Последний раз взываю к разуму. Гит нихрена не подходящее решение для системы

Попрошу перестать, не дай бог недалекие люди вашему бреду поверят. Git довольно популярен в небольших командах для деплоя конфигов и железок и разного рода софта.

Изменено 17 июля, 2015 пользователем ttttt

[sexst]

Git прекрасно работает с сотнями тысяч мелких файлов.

Да прекрасно-прекрасно, не бомбите пуканом. Только медленно.

 

Ну что же, жду появления чего-то на основе git, что хоть как-то покроет все нужные нам требования. Без "запретить", "не нужно" и прочего. До этих пор все ваши фанатствующие вопли ничего не стоят, а у меня лично к разработчикам noc и тестам больше доверия. Git пока буду использовать по его изначальному назначению. Я вообще люблю использовать вещи по назначению =)

[ttttt]

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

[MMM]

Есть положительный опыт хранения конфигов железа и даже серверов на linux в git примерно с 2012 года. Очень удобно, бэкапится элементарно копированием, либо rsync/rsnap по желанию, можно вообще поставить в крон git pull на бэкапном сервере и он сам будет забирать изменения. Также автоматически упаковываются мелкие объекты, но при желании можно сделать вручную или в кроне git gc --aggressive

[sexst]

MMM, а о каком числе файлов и их объёме в сумме идёт речь? У меня вот всплыли две основные проблемы: скорость и интеграция в общую систему.

 

 

ЗЫ: Как человек, познавший всю боль неатомарного бэкапа, хочу передать привет людям, делающим при помощи просто cp или rsync резервные копии данных, которые внезапно кто-то может начать обновлять =) И сакральную истину: не важно насколько сложно снимается резервная копия, важно насколько быстро, просто и реально из неё восстановиться.

И да, даже про гит есть не одна история как что-то ломалось в .git из-за кривого копирования/битого диска/бага фс, и это долго и муторно разруливалось.

[MMM]

MMM, а о каком числе файлов и их объёме в сумме идёт речь? У меня вот всплыли две основные проблемы: скорость и интеграция в общую систему.

 

 

ЗЫ: Как человек, познавший всю боль неатомарного бэкапа, хочу передать привет людям, делающим при помощи просто cp или rsync резервные копии данных, которые внезапно кто-то может начать обновлять =) И сакральную истину: не важно насколько сложно снимается резервная копия, важно насколько быстро, просто и реально из неё восстановиться.

И да, даже про гит есть не одна история как что-то ломалось в .git из-за кривого копирования/битого диска/бага фс, и это долго и муторно разруливалось.

в репозитории с конфигами чуть больше 100к файлов, папка .git весит 2,5Гб

 

"Атомарный" бэкап, например, используем для большой базы mysql (около 200Гб). Для этого базу разместили на lvm и в часы наименьшей нагрузки делаем lvm snapshot, который потом монтируем readonly и копируем на бэкапный сервер. Перед созданим snapshot делается set global innodb_max_dirty_pages_pct = 0 , FLUSH TABLES , FLUSH TABLES WITH READ LOCK и несколько раз sync . Восстанавливается обычно довольно быстро, mysql откатывает изменения по логу до целой транзакции.

 

.git сломаться может, но если есть клонированный репозиторий, у которого апдейты затягиваются через git pull, то вероятность поломки сильно снижается.

UPD. Не поломки, а утраты данных. Для того, чтобы починить, нужно всего лишь сделать git clone обратно и поменять в конфиге url

Изменено 19 июля, 2015 пользователем MMM