Distributed Systems — выпуск 6

Глава начинается с сущностей, которые мы хотим найти, — хостов, принтеров, дисков, файлов, процессов, — и с трёх терминов. Адрес это точка доступа, и главное его свойство в том, что он меняется: сущность переезжает. Книжный пример участники сразу называют устаревшим: при смене интернет-провайдера менялся и почтовый ящик. Алексей вспоминает, как на заре интернета вместе с адресом выдавали ящик в системе провайдера, — свой первый, полученный в Долгопрудном, он так и не открыл. Живой аналог нашли тут же: адрес меняется при смене работы. У настоящего идентификатора три свойства: он указывает на одну сущность, сущность связана ровно с одним идентификатором, и он не меняется и не переиспользуется. Человекочитаемые имена нужны потому, что передавать идентификаторы человеку неудобно. Дальше вся глава про то, как превратить имя в адрес: через таблицу сопоставления, как в DNS, или доведя сам запрос до нужного узла.

Плоское именование разбирают по четырём подходам. Простейший — broadcast: запрос уходит всем, машина узнаёт свой адрес и отвечает адресом канального уровня; на объёме приём перестаёт работать, и авторы переходят к multicast, где обращаются к группе, а заодно так делают репликацию. Внутри того же подхода — цепочки пересылок: при переезде по старому адресу остаётся ссылка на новый. Аналогии посыпались одна за другой: бесконечные форварды письма, редиректы 301 и 302, метка на перенесённом репозитории, сборщик мусора, оставляющий ссылки на месте перемещённых блоков. Цепочка рвётся и растёт, поэтому её схлопывают до одной ссылки — хотя, оговариваются участники, это не универсально. Второй подход, home-based, развёрнут в стандарте Mobile IP: домашняя точка знает текущее местоположение, пересылает запрос и параллельно отдаёт клиенту новый адрес, так что клиент замечает разве что лишние задержки, зато доступность дома становится критичной. Александр, который при чтении книги ходит по RFC, показал оттуда аскетичную ASCII-схему туннелирования.

Третий подход, распределённые хеш-таблицы, участники обсуждают через их свойства: автономность и децентрализация, устойчивость к отказам, масштабирование. Задача — найти по ключу узел, который его хранит, так, чтобы появление или выпадение ноды не приводило к полной перебалансировке; отсюда consistent hashing. Chord авторы дают как самую простую систему, а одной из самых популярных DHT Александр называет торренты; Cassandra шардируется по тем же принципам, хотя её модель данных сложнее. Отдельно упоминают хеширование с учётом локальности: похожие ключи ложатся рядом, и сканирование диапазона не разъезжается по узлам. В кольце ключ обслуживает нода с ближайшим большим идентификатором, причём идентификаторы одни и те же для нод и для ключей; наивная передача по кругу даёт линейный поиск в среднем по половине кольца, а finger table с шагами в степенях двойки сводит его к логарифму. Александр признаётся, что в первый раз хотел забить на Chord, но в новом издании его не убрали — и, разобравшись, увидел бинарный поиск по закольцованному пространству ключей.

Четвёртый подход — иерархический: верхние узлы знают не точное место сущности, а лишь то, что она где-то под ними, поэтому поиск идёт снизу вверх до узла, знающего нужную ветку, и оттуда вниз. У реплицированной сущности хранятся две ссылки, и стрелки расходятся по дереву в обе стороны. На этом месте у Александра отвалился Wi-Fi, Алексей подхватил рассказ, а вернувшийся Александр пошутил, что осталось найти шнурок и обеспечить себе надёжность. Заканчивается плоское именование вопросом доверия: по идентификатору не видно, ту ли сущность вернули. Простое решение — считать идентификатор от самих данных, но оно годится только для неизменяемого контента, для меняющегося авторы предлагают схему сложнее. Что именно они предлагают для безопасного разрешения имени, Александр честно не понял: авторы отсылают к главе про византийские отказы и намекают на централизованный узел, подтверждающий валидность ответа.

Структурированные имена начинаются с графа именования, устроенного как файловая система, и с мысли, что разбор имени держится на неявном знании структуры: понял, что перед тобой телефонный номер или путь, — знаешь, как разбирать. В Unix стартовый узел это суперблок, ведущий через индексные ноды в корневую директорию, а дальше жёсткие ссылки и символические с полным путём внутри; один из участников вспомнил, как больше десяти лет назад катил релизы переключением такой ссылки — рядом лежит старая версия, откат мгновенный. Монтирование склеивает два дерева: в NFS указывают протокол, сервер и монтируемую часть, почти как в URL. DNS авторы делят на три уровня: редко меняющийся глобальный с корневыми узлами, административный в зоне ответственности организаций и нижний, который, соглашаются участники, уже не совсем DNS. Александру классификация показалась не прибитой гвоздями: полезнее смотреть, как часто меняются записи и как быстро надо отвечать на запросы.

Разрешение имени бывает итеративным, когда клиент сам идёт от корня, и рекурсивным, когда всю работу берёт на себя сервер; корневые узлы работают только итеративно, а свой резолвер организации выгоден кэшем. Из записей разобрали A, CNAME как символьную ссылку и PTR для обратного поиска. Компании, которые вместо своего резолвера берут публичный, отдают историю запросов чужой стороне и получают не ближайший к себе сервер, а DNS over HTTPS прячет сами запросы от чужих глаз. Именование по атрибутам — это триплеты RDF, промышленного применения которых Александр не встречал, и LDAP, скрестивший иерархию с атрибутами; главной шуткой главы Александр называет ремарку авторов, что качество реализаций мешает таким службам распространиться. Искать предлагают распределёнными индексами с пересечением ответов или кривой Гильберта, кладущей близкие значения рядом, — тут вспомнился доклад про матчинг по атрибутам в дейтинге. Последняя тема, named data networking, заменяет адресацию пакетов выборкой данных по имени: роутер отдаёт из кэша, ждёт по таблице запросов или пересылает дальше. Участники сравнили её с IPFS и вебом 3.0, но в дикой природе не встречали.