Выполнение моего собственного динамического хостинга записи DNS
Идентичная копия Ваших данных хранится на каждом диске (если массив не "грязен" — например, если питание потеряно после записи в диск 0, но прежде, чем записать в диск 1). Однако метаданные отличаются; это позволяет mdadm и md говорить эти два диска независимо.
Можно ли подкачать кабели вокруг?
Можно подкачать кабели на этих двух дисках. Когда Вы (или сценарии начальной загрузки Вашего дистрибутива) делаете mdadm --assemble на массиве mdadm смотрит на метаданные по каждому диску, и от этого выясняет, который является диском 1 и который является диском 2.
Это на самом деле чрезвычайно гибко — Вы могли, например, удалить один из дисков, поместить его в корпус USB-SATA и присоединить его к USB-порту, и mdraid все еще будет совершенно счастлив.
Я могу восстановить ухудшенный массив при помощи dd?
Нет. Если бы Вы сделали это, то у Вас было бы два диска 1's или два диска 2's, и mdadm был бы перепутан (и, я не протестировал это, но я предполагаю, что он отказался бы собирать массив).
В целом все управление массивами, покончили mdadm и далее это редко - хорошая идея обойти mdraid. Для восстановления массива Вы добавляете новый диск/раздел к нему. Что-то вроде этого, принимая sdb1 раздел на замещающем диске:
mdadm --add /dev/md0 /dev/sdb1
mdraid затем скопирует данные, и можно наблюдать состояние cat /proc/mdstat. Вы свободны продолжить использовать массив во время пересинхронизации. Нет никакой потребности загрузиться с живого CD или подобный (необходимо смочь загрузиться от ухудшенного массива). На самом деле, если у Вас есть лотки замены в горячем режиме в Вашей машине, можно заменить неудавшийся sdb как это:
mdadm -r /dev/md0 /dev/sdb1- Удалите диск
- Вставьте новый диск
- Разделите новый диск (часто, но не всегда, будет sdb снова).
mdadm -a /dev/md0 /dev/sdb1
Это не требует никакого времени простоя.
Обратите внимание также, что, если Вы загружаетесь от зеркала, необходимо удостовериться, что загрузчик (например, личинка) установлен на обоих дисках. Как сделать, это зависит от Вашего дистрибутива.
Что-нибудь еще?
Да. mdadm --create не шаг восстановления. Это используется для создания нового, пустого массива, и следующий шаг обычно был бы pvcreate или mkfs. Уже существующие массивы запускаются с помощью mdadm --assemble. (Это, кажется, достаточно общая ошибка и имеет потенциал для уничтожения данных.)
Заключительные комментарии
Необходимо, вероятно, взять немного для ознакомления с mdraid документацией (Вы доверяете ей свои данные, в конце концов). В частности, прочитайте mdadm страница руководства, любая документация RAID Ваш дистрибутив производит, и Documentation/md.txt (из источников ядра, соответствуя Вашей версии ядра). Это, вероятно, не самые понятные документы, но они все обычно актуальны.
Существует также Набег Linux Wiki, но остерегайтесь этого не все, что там полностью актуально.
Существуют другие страницы там, но быть особенно осторожными чего-либо упоминание mkraid или /etc/raidtab кроме как исторический очерк, как те инструменты имеют быть устаревшими в течение десятилетия.
]Я делаю следующее, что хорошо работало для меня последние 10+ лет. Я устанавливаю динамическое DNS имя на такой службе, как []DynDNS[] (которая до этого года была бесплатной) или на каком-нибудь другом таком провайдере. Это дает мне основу для того, чтобы мой постоянно меняющийся IP всегда был основан на статическом имени, таком как sam.dyndns.org.[
] []Затем я создаю CNAME в привязке, которая указывает на это статическое имя, и вуаля у меня есть постоянные имена.[
].Хотя у BIND есть поддержка DDNS, его настройка немного утомительна, так как вам нужно создать ключи аутентификации, потому что обновления, похоже, обрабатываются через сам протокол DNS, чтобы обновления могли поступать с другого компьютера. работает сервер BIND, поэтому для этого, конечно же, требуется безопасный механизм аутентификации.
Я сам собирался пойти по этому пути, но вместо этого мой домен был размещен на сервисе Amazon Route53. У них есть API для обновления записей, которые можно использовать для динамических IP-адресов. Я установил низкий TTL для этой одной записи, и на моей машине есть cronjob, который ищет мой текущий IP-адрес и обновляет запись Route53, если мой IP изменился.
Стоимость на момент написания статьи составляет около 0,90 долларов США в месяц, поэтому это не бесплатно, но это кажется вполне разумным для моего варианта использования, учитывая избыточность и отказоустойчивость, встроенные в службу. Остальные мои записи DNS тоже там, потому что стоимость указана за зону -, независимо от того, сколько записей вы на самом деле поместили в зону.
Я использую awsинструменты командной строки вместе со сценарием, подобным этому (запускаемому из cron раз в час )для обновления записи Route53 при изменении моего IP:
#!/bin/sh
function updateDNS
{
TARGET_ZONEID="$1"
TARGET_FQDN="$2"
IP="$3"
CUR_IP="$4"
TYPE="$5"
if [ "$IP" != "$CUR_IP" ]; then
echo '{ "Comment": "DDNS update", "Changes":[ { "Action":"UPSERT", "ResourceRecordSet":{ "ResourceRecords": [ { "Value":"'"$IP"'" } ], "Name": "'"$TARGET_FQDN"'", "Type": "'"$TYPE"'", "TTL": 60} } ] }' |
aws route53 change-resource-record-sets --hosted-zone-id "$TARGET_ZONEID" --change-batch file:///dev/stdin > /dev/null
fi
}
TARGET_ZONEID="ABC123"
TARGET_FQDN="homeip.example.com."
IP=`dig +short myip.opendns.com @resolver1.opendns.com`
CUR_IP=`dig +short "$TARGET_FQDN"`
TYPE="A"
updateDNS "$TARGET_ZONEID" "$TARGET_FQDN" "$IP" "$CUR_IP" "$TYPE"
# Can add more updateDNS calls to do other hosts, AAAA records, etc.
Я запускаю этот скрипт с нескольких хостов в сети, чтобы, если один из них вышел из строя, IP-адрес все равно обновлялся.