Сетевое администрирование в UNIX, 06 лекция (от 29 марта)
Материал из eSyr's wiki.
Бэкапы rsync -r путь1 путь2
iSCSI транслируем по сети скази команды
nfs монтируем кусок поддерева на бакэп сервере и работаем с ним также как с любой другой папкой
Одним из преимуществ нфса перед виндоус протоколами это то что она поддерживает софтлинки и хардлиники. Если у нас на изначальном серевере есть папка /export/0.txt /export/b.txt мы с помощью рсинка делаем /backup/export/0.txt /backup/export/b.txt, рсинк создал дерево, все замечательно. Следующие бэкапы используем hardlink пред. бэкап копируем при помощи создания жестких ссылок. То есть директории создаем, а файлы делаем хардлинки. рсинк умеет это с ключом -h, cp кажется тоже с ним же. Поскольку физически создание файла не происходит, а происходит прописание связи имя-инод в файле директории, то это операция присходит достаточно быстро. После этого мы можем сказать рсинк нашей директории и новой директории. То есть если у нас в данный момент возник c.txt, то он создастся и в бэкапе. рсинк сравнивает время размер и так далее файлов директории которую мы хоти бэкапить с файлами в нвовой директории.
Следующий бэкап у нас уже дает копию от ехпорта1 и в нём будет файл с.тхт Если к последующему варианту время изменения файла поменяется. то он будет изменён. Нужно быть осторожным, и пользоваться ключом, что если файл изменился, то предыдущий полностью удаляется и ноый пишется. Вобщем методик бэкапа ровно две -- dump или rsync. Перед бэкапом надо делать снапшот. Дамп работает только со снапшотами, потому что нехрошо делать рсинк когда ваша система меняется. В zfs это делается вообще мгновенно. Основная идея zfs это copy on write, то есть данные всегда перещаписываются на новом месте. В нфсе надо делать кучу действий.
Встает вопрос файловой системы на сервере, на котором хранится бэкап.
Влинуксе рейд6 есть?
рейд 5 избыточность 1, рейд 6 избытоность в два диска.LLVM.
Похожие технологии. ЛЛвм позволяет вам создавать рейд из разных устройств, зфс тоже позволяет создавать разные рейды с различной избыточностью.
Одним из перимуществ зфс является то, что она может создавать партиции на ходу как часть дерева. Если у нас уже есть некоторое дерево, а мы говори что у нас будет еще одна партиция с путем от корня таким то, то она спокойно его создаст. В обычной фс если вы выделили пртицию под хоум 20 гб, то вы ничего с ней делать не сможете. Здесь все место -- один большой пул который между партициям и рапределяется. Можно задать ограничение на разме и тогда партиция директория не сможет превысить это тразмер. Это хорошо когда мы дампом хоотим копировать не всю систему, а часть.
Различные стратегии сколько бэкапов хранить. С одной стороны хочется их делать и чаще, и глубина хранения была побольше(то есть чтоб недельные изменения хранились). Если мы делаем бэкап каждый час.
Можно использовать след схему -- храним по одному бэкапу на ту периодичность, которую можем обеспечить втечене суток, храним по одному бэкапу на день недели и по одному бэкапу на месяц(считая, что каждые 4 недели ээто месяц). В нашем примере из 24. Переброс бэкапа из суточного в недельный, из недельного дальше сводится к перименованию
h0, h1, .. h23
d0, d1,.. d6
w0,w1,w2,w3
m0,m1,..m11
Для дополнительной скорости можно длеать снапшоты на сервере, потому что создание снапшотов это быстро. В зфс несколько секунд, в нфс около 5 минут. Недостаток большого количества снапшотов -- если у вас происходит большое колво операций ввода вывода, то снимок он же должен заморозить файловую систему, выв можете обнаружить, что увас кончается место, вы удаляете файл, а он не удаляется, потому что лежит в снимке.
Вопрос: а если у нас что-тобыло открыто пока мы делали бэкап?
Как раз для этого и нужны снимки файловой системы
Вопрос: снапшот делается в течение 5 минут, что происходит с изменниями ха эти 5 минут?
Это работа ос. Она может эти 5 минут складывать изменеия в кэши, например.
Минусы зфс -- она склонна к фрагменироанию.
Гарантированное удаление файлов -- плохо работает с ссд, потому что сложно угадать как какой работает. Ты ему гворишь запиши
в 5 сектор нули. Он пишет в другой сектор и переименовывает его в 5ый.
Итак, мы хотим создать избыточность. У нас есть два сервера, несколько клиентов
инт
158.250.11.1
сервер1 серврер2
192.168.0.1
клиент1 клиент2 клиент3 клиент4
Можно переключать вручную.
Если мы хотим, чтобы это делалось автоматически, то нам нужно две вещи. Первая вещь -- переключение интерфейсов. За это у нас отвечает протокол carp. опенбздшый протокол, который создан лишь бы не походить на цисковский, который за лицензиями. Нам нужно два интерфейса один нутренний, один внешни carp0, carp1
У каждого интерфейса в протокле карп есть понятие номер группы и вес. группа 1-255, вес 0-240. требование -- одни и те же интерфейсы должны находится в одной сети. Чтобы найтись они посылают спец запросы попротоколу карп. Чтобы их не могли подделать есть такое понятие как пароль, который должен быть одинаковым у сервер1 и сервер2.
Грубо говря, приходт запрос, кто такой 10.0.1.1 и один из серверов должен ответить. Главным будет тот, кто первым ответит на карп запрос. Сервера отвечают с периодичностью секунда+свой вес. Если сервер1 отвечает рньше чем серер2 то теперь он понимает, что он главный. Точно также и для внешнего интерфейса. Все это конечно хорошо, теперь у нас с1 и с2 автоматически принмиают соединения, но что делать с установишимися соединениями, особенно если у нас там был нат, мы запмнили какие порты куда транслировать.. с2 про них вообще говоря ничего не знает. В приниципе карпом мы можем балансироать нагрузку. В с1 есть набор фв правил, и он помнит некоторые сосотяония. В принцпие есть отдельно в пфе возможность синхронизации, чтобы соответственно с2 знал про все эти состояния, которые находятся на сервере с1. pfsync. пфсинк никак не шифруется. считается приличным соединять интерфейсы пфсинка аплинком.
Влинуксе тоже есть чтото такое.
Давайте рассморим что-нибудь простое, что вас интересует. Если мы хотим, чтоб у нас синхронизировался кэш сквида, то его можно синхронизироать бэкапами.
clone- делается со снапшота, досутпен для записи
