1) Да.
2) Скиньте, пожалуйста, в личку IP-адрес с которого отправлялись запросы и, желательно, Ваше географическое местоположение. Также такая ситуация может быть во время работ, либо в результате фейловера.
На самом деле проблем с подключением никаких нет и всё может работать через один сетевой интерфейс сервера, т. к. в плане настройки в ОС anycast IP-адрес ничем не отличается от IP-адреса для управления. Основная разница «снаружи»: маршруты для первого могут вести на разное географически распределённое оборудование, а для второго — только на конкретный сервер. Ну а анонсы можно запускать через этот же сетевой интерфейс, с адресами интерфейса они по сути не связаны.
На данный момент суть не в том что DNSSEC плохой и нам не нравится. Дело в востребованности со стороны клиентов. Как бы печально это ни звучало, но если я сейчас ради 2,5 пользователей проделаю, хоть и интересную, но трудоёмкую работу… тогда все остальные более востребованные фичи клиентам придёться ждать гораздо дольше.
SSHFP чтобы не отвечать yes
Сначала пользователь должен сделать соответствующую RR, что может занять больше времени. Как много новых пользователей ходит по ssh на этот сервер, где они не набирают 'yes'? Или вы всегда подключаетесь с разных машин где не сохранены отпечатки?
Опять же, я не против этого типа записей, в планах они тоже есть. Но недостаточно выкатить сырую фичу просто для галочки, нужно чтобы это действительно было удобно и имело смысл.
Почему Вы сегодня доверяете регистратору возможность указания master-серверов DNS для домена но боитесь доверить ключи для подписания зоны?
Договор, а вообще я не доверяю, но не делать же своего регистратора ради своих доменов?
Если не хотите доверять ключи, пусть провайдер DNS позволит размещать уже подписанную зону без хранения ключей.
Этот вариант точно будет реализован. Есть также проблема введения новых географических узлов в случае использования клиентом функционала балансировки по маршрутизации или фэйловера на уровне DNS: клиенту на своей стороне каждый раз нужно будет подписывать зону во всех возможных вариантах.
Безусловно, в каждой географической точке расположены выделенные серверы, которые и обрабатывают клиентские запросы. Серверы держат с операторами BGP-сессии, что позволяет нам самостоятельно манипулировать анонсами. Должен отметить при таком раскладе очень удобно проводить обслуживание:
1. Прекращаем анонсировать сеть, которую может затронуть работами — запросы в течение максимум минуты распределяются по другим географически распределённым узлам. Для клиентов это почти незаметно, единственный побочный эффект — небольшое увеличение времени ответа за счёт увеличения расстояния до ближайшего доступного узла.
2. Проводим необходимые работы.
3. Проверяем что всё в порядке и узел отвечает на все запросы корректно.
4. Начинаем анонсировать сеть. Запросы на узел начинают идти в течение 10 секунд.
В качестве инструмента автоматизации используется Ansible. Работает через ssh и не требует на удалённом узле установки каких-либо дополнительных пакетов, кроме питона, который как правило уже есть в минимально установленной ОС. На обновление узла уходит около минуты — основное время это ожидание когда разойдётся информация по маршрутизаторам провайдеров и прекратятся DNS-запросы.
Для мониторинга и статистики DNS-запросов используется самописаная система. Да, мы знаем какие записи доменов спрашивали, сколько раз и когда. При большом желании можем даже сказать кто именно (как правило это рекурсоры провайдеров пользователей, что не удивительно). Также мы знаем какие RR-записи спрашивают, но наши пользователи их по какой-либо причине не прописали (самая распространённая отсутствующая — AAAA-запись, т.к. рекурсоры спрашивают её в первую очередь).
Процесс добавления ноды происходит достаточно просто — установка системы, накатывание своей обвязки для управления, запуск репликации и мониторнга. Самый интересный этап — начало анонсирования, в эти моменты я держал пальцы скрещенными чтобы запросы распределялись между нодами равномерно и следуя хоть какой-то логике.
Самое сложное — это сделать так чтобы запросы приходили туда куда они должны приходить с наименьшими задержками, а не как хотят операторы, желающие урвать денег побольше, наплевав на своих пользователей (есть у нас в России, запросы из Хабаровска уходили в Киев мимо Екатеринбурга, СПб и Москвы). Основной метод исправления — prepend'ы на анонсах, главное не переборщить.
DNSSEC в планах есть. Однако на данный момент самая большая сложность не в том чтобы подписать зону, а в том что у большинства отечественных пользователей рекурсоры провайдеров и их дешёвые роутеры не поддерживают DNSSEC.
Также есть крайне сложный вопрос: делегировать подпись dns-провайдеру (т.е. ключи будут находиться не только у владельца зоны) или загрузить файл с уже самостоятельно подписанной зоной в панель управления хостера?
Первый метод удобен, но второй способ гарантирует что никто кроме Вас не сможет изменить и подписать записи зоны. Лично я выбрал бы второй, но что делать если мне захочеться/нужно воспользоваться услугами хостера для фэйловера на уровне DNS или для балансировки нагрузки по географическому местоположению?
Ещё сделать мастером можно так: $ pg_ctl -D /path/to/data/dir promote
Строчки с wal_level, max_wal_senders, wal_keep_segments, archive_mode, archive_command комментировать на слэйвах не обязательно, тогда и с триггер-файлом должно работать, но сам не пробовал.
При синтетических тестах (pgbench) pgpool-II с двумя нодами (балансинг + полер) проигрывал pgbouncer'у на одной, даже более того: pgpool-II проигрывал чистому postgre без пулера соединений. Вывод: использовать pgpool-II для балансинга+пулер следует только в случае очень тяжёлых запросов, иначе только теряем в производительности.
По умолчанию он асинхронный, синхронность надо включать отдельно параметром synchronous_standby_names. В качестве значения параметра — хостнеймы или application_name (указывается в recovery.conf) слэйвов.
Грабли на которые я напоролся при синхронной репликации: если слэйв один и он упал, то мастер на все запросы записи в базу тупо не будет отвечать ибо он ждёт когда эти данные не запишутся уже лежащий слейв. synchronous_standby_names можно менять на лету и отключить репликацию, но уже «висящие» запросы придётся как-то убивать.
PowerDNS — безумный комбайн, который может работать с несколькими бэкендами одновременно, включая mysql, postgresql, mongodb (вроде пока экспериментально) и даже так называемый pipe-backend, когда для получения данных для ответа запускается пользовательская программа, в том числе и bash-скрипт. Подробнее про бэкенды можно почитать тут.
Моё предположение на примере hulu.com, для других не смотрел:
hulu пользуется akamai для географического распределения нагрузки. Если мы втупую пойдём на hulu.com наш повседневный резолвер идёт на NS-серверы akamai и получает A-запись сервера, который заранее знает что нам давать доступ к сервису нельзя. Указанные в статье рекурсоры скорее всего просто не отдают наш реальный ip NS-ам akamai и получают в ответ RR как будто они находятся на территории США (или ещё где-то).
Как я понял, для того чтобы заработало нужно резолвить через волшебные DNS'ы не только зоны сервисов, но и сопутствующие зоны к которым обращаются страницы этих сервисов.
Гугловые 8.8.8.8 и 8.8.4.4 при выполнении рекурсивного запроса передают NS-серверам akamai наш реальный ip, вследствие чего нас отправляют на серверы, с которых смотреть нельзя.
Так же возможно что они отдают свои подставные ip для определённых зон чтобы обмануть плеер сервиса.
На достоверность не претендую. Если ошибся — поправляйте.
На сколько я помню, в каком-то драйвере переключения раскладок MS-DOS'а по дефолту как раз и был бинд на левый и правый CTRL. А чтобы игрушку запустить нужно было выпилить вообще поддержку кирилицы (640kb хватит всем!).
Реквестирую руководство по подключению USB аудио карты к точке доступа.
В теории-то понятно как это сделать, но хотелось бы узнать о возможных граблях и как их обойти заранее.
2) Скиньте, пожалуйста, в личку IP-адрес с которого отправлялись запросы и, желательно, Ваше географическое местоположение. Также такая ситуация может быть во время работ, либо в результате фейловера.
Сначала пользователь должен сделать соответствующую RR, что может занять больше времени. Как много новых пользователей ходит по ssh на этот сервер, где они не набирают 'yes'? Или вы всегда подключаетесь с разных машин где не сохранены отпечатки?
Опять же, я не против этого типа записей, в планах они тоже есть. Но недостаточно выкатить сырую фичу просто для галочки, нужно чтобы это действительно было удобно и имело смысл.
Договор, а вообще я не доверяю, но не делать же своего регистратора ради своих доменов?
Этот вариант точно будет реализован. Есть также проблема введения новых географических узлов в случае использования клиентом функционала балансировки по маршрутизации или фэйловера на уровне DNS: клиенту на своей стороне каждый раз нужно будет подписывать зону во всех возможных вариантах.
1. Прекращаем анонсировать сеть, которую может затронуть работами — запросы в течение максимум минуты распределяются по другим географически распределённым узлам. Для клиентов это почти незаметно, единственный побочный эффект — небольшое увеличение времени ответа за счёт увеличения расстояния до ближайшего доступного узла.
2. Проводим необходимые работы.
3. Проверяем что всё в порядке и узел отвечает на все запросы корректно.
4. Начинаем анонсировать сеть. Запросы на узел начинают идти в течение 10 секунд.
В качестве инструмента автоматизации используется Ansible. Работает через ssh и не требует на удалённом узле установки каких-либо дополнительных пакетов, кроме питона, который как правило уже есть в минимально установленной ОС. На обновление узла уходит около минуты — основное время это ожидание когда разойдётся информация по маршрутизаторам провайдеров и прекратятся DNS-запросы.
Для мониторинга и статистики DNS-запросов используется самописаная система. Да, мы знаем какие записи доменов спрашивали, сколько раз и когда. При большом желании можем даже сказать кто именно (как правило это рекурсоры провайдеров пользователей, что не удивительно). Также мы знаем какие RR-записи спрашивают, но наши пользователи их по какой-либо причине не прописали (самая распространённая отсутствующая — AAAA-запись, т.к. рекурсоры спрашивают её в первую очередь).
Самое сложное — это сделать так чтобы запросы приходили туда куда они должны приходить с наименьшими задержками, а не как хотят операторы, желающие урвать денег побольше, наплевав на своих пользователей (есть у нас в России, запросы из Хабаровска уходили в Киев мимо Екатеринбурга, СПб и Москвы). Основной метод исправления — prepend'ы на анонсах, главное не переборщить.
Также есть крайне сложный вопрос: делегировать подпись dns-провайдеру (т.е. ключи будут находиться не только у владельца зоны) или загрузить файл с уже самостоятельно подписанной зоной в панель управления хостера?
Первый метод удобен, но второй способ гарантирует что никто кроме Вас не сможет изменить и подписать записи зоны. Лично я выбрал бы второй, но что делать если мне захочеться/нужно воспользоваться услугами хостера для фэйловера на уровне DNS или для балансировки нагрузки по географическому местоположению?
Вопрос без подвоха, чистое любопытство, ибо живьём WP{7-8} не видел.
$ pg_ctl -D /path/to/data/dir promoteСтрочки с wal_level, max_wal_senders, wal_keep_segments, archive_mode, archive_command комментировать на слэйвах не обязательно, тогда и с триггер-файлом должно работать, но сам не пробовал.
Грабли на которые я напоролся при синхронной репликации: если слэйв один и он упал, то мастер на все запросы записи в базу тупо не будет отвечать ибо он ждёт когда эти данные не запишутся уже лежащий слейв. synchronous_standby_names можно менять на лету и отключить репликацию, но уже «висящие» запросы придётся как-то убивать.
hulu пользуется akamai для географического распределения нагрузки. Если мы втупую пойдём на hulu.com наш повседневный резолвер идёт на NS-серверы akamai и получает A-запись сервера, который заранее знает что нам давать доступ к сервису нельзя. Указанные в статье рекурсоры скорее всего просто не отдают наш реальный ip NS-ам akamai и получают в ответ RR как будто они находятся на территории США (или ещё где-то).
Как я понял, для того чтобы заработало нужно резолвить через волшебные DNS'ы не только зоны сервисов, но и сопутствующие зоны к которым обращаются страницы этих сервисов.
Гугловые 8.8.8.8 и 8.8.4.4 при выполнении рекурсивного запроса передают NS-серверам akamai наш реальный ip, вследствие чего нас отправляют на серверы, с которых смотреть нельзя.
Так же возможно что они отдают свои подставные ip для определённых зон чтобы обмануть плеер сервиса.
На достоверность не претендую. Если ошибся — поправляйте.
В теории-то понятно как это сделать, но хотелось бы узнать о возможных граблях и как их обойти заранее.