Честно говоря в контексте той задачи мы не рассматривали duplicity и dar. Хотя мы с ними знакомы.
В нашем случае принципиально было сделать легкое решение на базе rsync, поэтому не долго думаю мы начали писать свой скрипт.
Насчет контейнеров — верно. Мы практически везде их используем, но мы их неограничиваем. И использовать ploop для нас нет смысла, поскольку контейнер обычно занимает весь раздел.
Нет, это все-таки немного попроще чем rsnapshot.
Rsnapshot не подошел как раз потому, что нам нужен бекап с клиентского сервера на сервер бекапов.
Хардлинки делает rsync c опцией -H
rsync --help
… -H, --hard-links preserve hard links
Во-первых, эта статья не претендует на звание конечной истины, не стоит столь критично относится ко всему, что здесь написано.
Во-вторых, что-то я еще нигде не видел организаций, где бы нанимали каких-то админов с «соответствующими скиллами» для внедрения виртуализации, разве что в гос. конторах для прокачки бабла. В нормальных организациях, не обучаемых админов, обычно не держат подолгу.
В-третьих, про точку отказа я пожалуй забыл сказать, но не «старался». Но кто-то сказал, что нельзя строить отказоустойчивых решений с помощью например технологий VMware и прочих признанных вендоров? И резервное копирование никто не отменял.
И потом, я же призывал никого слепо кидаться что-то внедрять. Естественно, нужно просчитывать многие вещи, прежде чем внедрять новые технологии, это должен знать и понимать хороший ИТ-руководитель.
Насчет проплаченного это вы зря так. Я же не за деньги эту статью написал.
Честно говоря были планы, проанализировать разные технологии, но пока материала недостаточно (есть данные по KVM, OpenVZ, LXC).
Виртуализация тема широкая, одной статьи мало. Если будет время и будут возможности, буду продолжать.
Верно, но что по вашему контейнерная виртуализация, или полная виртуализация не упрощает процесс деплоя ПО? Один раз правильно настроенный и отлаженный шаблон ВМ или контейнера не упрощает жизнь админу? Дальнейшее сопровождение тоже можно свести к минимуму.
Время на настройку и обслуживание виртуальных серверов тратиться меньше, поэтому появляется возможность справляться с такой работой меньшим количеством сотрудников.
О производительности мне сложно судить, пока внедряли в основном на dev-окружениях. Есть один боевой проект, там отставаний не замечено, но и нагрузка средняя.
Ява есть ява, мастер процесс, к примеру, кушает где-то ~500 Мб, слейв чуть меньше. Процессорного времени кушает мало.
В нашем случае принципиально было сделать легкое решение на базе rsync, поэтому не долго думаю мы начали писать свой скрипт.
Насчет контейнеров — верно. Мы практически везде их используем, но мы их неограничиваем. И использовать ploop для нас нет смысла, поскольку контейнер обычно занимает весь раздел.
--link-dest=DIR hardlink to files in DIR when unchanged
Насчет датацентров — по разному, иногда в одном и том же, иногда в разных странах серверы.
Хардлинки делаются не долго. Из цифр которые я приводил в конце статьи, это можно примерно понять.
Rsnapshot не подошел как раз потому, что нам нужен бекап с клиентского сервера на сервер бекапов.
Хардлинки делает rsync c опцией -H
rsync --help…
-H, --hard-links preserve hard linksВо-вторых, что-то я еще нигде не видел организаций, где бы нанимали каких-то админов с «соответствующими скиллами» для внедрения виртуализации, разве что в гос. конторах для прокачки бабла. В нормальных организациях, не обучаемых админов, обычно не держат подолгу.
В-третьих, про точку отказа я пожалуй забыл сказать, но не «старался». Но кто-то сказал, что нельзя строить отказоустойчивых решений с помощью например технологий VMware и прочих признанных вендоров? И резервное копирование никто не отменял.
И потом, я же призывал никого слепо кидаться что-то внедрять. Естественно, нужно просчитывать многие вещи, прежде чем внедрять новые технологии, это должен знать и понимать хороший ИТ-руководитель.
Честно говоря были планы, проанализировать разные технологии, но пока материала недостаточно (есть данные по KVM, OpenVZ, LXC).
Виртуализация тема широкая, одной статьи мало. Если будет время и будут возможности, буду продолжать.
Ява есть ява, мастер процесс, к примеру, кушает где-то ~500 Мб, слейв чуть меньше. Процессорного времени кушает мало.
Спасибо за замечания, учту.
Подробнее об архитектуре можно посмотреть здесь.
Трансформации поддерживаются с помощью фильтров.