DNS как распределенный кэш

DNS имеет смысл в некоторых случаях:

• Широко распределенные данные

  Например, черные списки DNS являются эффективными, потому что кэширующаяся инфраструктура уже существует около пользователей (т.е. их ISP), или для крупных пользователей они могут легко запустить заказное программное обеспечение как (rbldnsd). Однако точка - это, использует существующий широко развернутый протокол.

• Маленькие ответы (приблизительно 500 байтов макс.)

  Большинство интересных вещей, которые люди распределяют через DNS, является маленьким, и часто даже просто существование или не записи достаточно (например, DNSBL сигнализирует, что IP-адрес плох, или что-то, что сигнализирует, что контрольная сумма этого файла "плоха").

  Я записал это: https://dgl.cx/wikipedia-dns, и это в значительной степени раздвигает границы размеров ответа, которые можно безопасно сделать в DNS. Не все реализуют или поддерживают EDNS0 и как кто-то еще сказал, после того как Вы отступили к TCP, преимущество того, чтобы быть не сохраняющим состояние исчезает.

Поскольку другие сказали, что это звучит мне как, Вы были бы более обеспечены с чем-то как memcached. Попытка ограничить себя к DNS кажется глупой, когда это для внутреннего пользования. Если Вы управляете клиентом, можно легко сделать лучшее задание при обработке отказа и выравнивании нагрузки, чем сам DNS может сделать.

1 - вероятно, хотя не рекомендуемый
2 - нечетное поведение кэширования, небезопасное, никакая поддержка где угодно
3 - никакая идея

Существует по существу готовое решение для этого в memcached: http://www.danga.com/memcached/

Поскольку я - технический директор скептика, я хотел бы бросить некоторый цвет вокруг обсуждения.

Как Gary упомянул, приложение должно смочь опубликовать очень большую декларацию. Декларация будет разделена в некоторых (30-100) группы. Каждый ключ составит в среднем приблизительно 55 байтов, но мог быть намного больше.

Какой бы ни продукт мы выбираем потребности поддерживать следующее:

1) Полное резервирование и выравнивание нагрузки 2) Высокий объем сделки (15k-20k чтения/секунда) с <время отклика на 500 мс.

Хорошие имущим: 1) Иерархическая структура 2) Рекордное истечение, 3) Самоописывающее топологию

DNS, вытолканный в ум только после размышления об использовании UDP вместо TCP для получения данных из распределенного кэша в оперативной памяти. Естественно, DNS является одним из старых и самых больших приложений DNS.

DNS, как известно, поддерживает зональные файлы с очень большим объемом записей. Например, .com. является зональным файлом afterall (хотя распределено через многие серверы глобально). Это, как также известно, поддерживает очень высокие уровни трафика.

Мы выполнили DNS через некоторые предварительные тесты. Мы загрузили единственный зональный файл 10M записи TXT с представительным объемом данных. С другого сервера на той же LAN мы затем запустили тесты 300 000 запросов многопоточным способом и получили приблизительно 5 000 запросов в секунду. Сервер и клиент едва вздрогнули во время теста. Мы или сталкиваемся с узкими местами в самом приложении тестирования или в сетевом стеке на клиенте.

Я заинтригован DNS, потому что он поддерживает все, что я хочу исходно, и имеет так много лет. Функции, которые я люблю:

 Zone Delegation - we can define which server(s) handle particular partitions.  For example 1.mycompany.local is handled by servers 10.1.1.1 and 10.1.1.2.
 Redundancy - DNS was built with resiliency and redundancy in mind.  It can also be easily load balanced.
 Performance - Proven to support high request volumes

Со все, что сказало, DNS, действительно походит на причудливый инструмент для использования в качестве кэша. Если бы это действительно заканчивает тем, что делало его через фазу выбора, мы абсолютно использовали бы его только на внутренней LAN, и это не будет на том же DNS как наши никакие другие внутренние или внешние системы DNS. Одно примечание стороны - то, что мы могли бы хотеть совместно использовать данные, которые мы храним со сторонними партнерами. DNS является известным объектом, который любой мог легко запросить для получения зональных передач из.

Спасибо за Вашу длительную обратную связь.

Это не плохая идея, в конце концов.

Если это о производительности, удостоверяются, что ответ соответствует к одному udp пакету (иначе, это будет нейтрализация к более медленному tcp). Установите значения TTL, мудро зависящие, как часто делают Вы хотите обновить записи.

Существует (стандартный) способ обновить записи динамично, которые могут быть хорошими, если Вы делаете это из программы.

если Ваша запись DNS является key.modulus, каковы данные? IP-адрес? я пропускаю что-то?

Используйте memcached. Это разработано для точно этой цели. Если Вы кэшируете данные, то Вы не должны волновать, когда данные сбрасываются. Если сервер исчезнет, то клиенты продолжат использовать другие серверы, и это будут просто считать неудачным обращением в кэш. Существуют клиенты, которые перехешируют в случае неудавшегося узла. Я думаю, что Last.fm сделал некоторую работу над ним.

Если Вам нужны надежные данные, то Вы могли бы хотеть посмотреть на что-то как memcachedb, который использует berkerleyDB бэкенд, а не память и сделает репликацию между двумя узлами.

1. это даже выполнимо?
   Да. Я предложил бы, чтобы Вы посмотрели на записи TXT для того, чтобы содержать эту информацию

2. каковы ловушки?
   Не уверен

3. как я измеряю серверы DNS.
   Не уверенный, но насколько я понимаю это, DNS является довольно низким сервисом требования с помощью UDP для обрабатывания запросов и ответов - как таковой, это до клиента, чтобы определить, получило ли это ответ или не, и повторно спросите, было ли это неудачно.

Первый признак, что Ваш DNS не работал, будет спорадическим предприятием широкие отказы поиска.

Отметьте также, что почти каждая компьютерная система, которая выполняет эти запросы, будет кэшировать результат за 30 минут или до записей ttl значение если его меньше чем 30 минут. Таким образом, тщательная обработка этих значений была бы необходима.

Я раньше размещал меню столовой на сервере пальца, так, чтобы все видели дневное меню

<сосут яйца>, я также предложил бы, чтобы Вы записали свою программу с определенным сервером/группами в памяти и не полагались на сервер DNS по умолчанию: O </сосут яйца>

В то время как DNS является большим для некоторых вещей, для хранения 512-килобайтовых значений, неважно, не хорошо, как Вы нарезаете его.

Если бы у Вас было 300 миллионов данных, которые были намного меньшими (скажите, 1 000 байтов), то DNS (с 1 280-байтовыми пакетами) мог бы быть хорошей идеей.

PowerDNS Авторитетный Сервер мог бы быть отличным способом опубликовать такие данные, например, с помощью бэкенда КАНАЛА.

Но для 512-килобайтовых данных, DNS не будет соответствовать Вашему счету вообще.

Больше информации о требованиях доступа/обновления было бы полезно для рендеринга большего обоснованного мнения.

Относительно самого DNS это главным образом оптимизировано для относительно статических данных, которые редко/медленно изменяются. Кроме того, по большей части это - установка для работы на относительно небольшой объем данных с единственной точки зрения сервера/зоны. Это добирается, это - масштабируемость главным образом от промежуточного кэширования (TTL) и также распределенная древовидная природа глобальной "базы данных" через серверы каждого organziation. Дублирующиеся серверы DNS больше, чтобы улучшить доступность... и не так распределить рабочую нагрузку (хотя она может иметь место в некоторых приложениях).

Ваше приложение, кажется, продвигает против мелкой частицы DNS, две области:

• Ваши записи не являются действительно настолько маленькими
• У Вас есть огромное количество записей для хранения

DNS мог бы быть сделан работать в Вашем приложении, но я ясно скажу, что это не оптимизировано для этого случая.

У меня никогда нет загрузки, протестированной DNS до этой степени, но я буду очень очень осторожен об этом подходе. Это является, конечно, неортодоксальным, и достаточно сумасшедшим, что просто могло бы работать, но подход похож на использование молотка для превращения винта - уверенный, что можно сделать это, если Вы устанавливаете вещи право, но это - неправильный инструмент для задания.

В худшем случае Вы принесли бы DNS компании к, он - колени, и у кого-то было бы задание объяснения генеральному директору, почему он не может получить свою электронную почту.

Я предлагаю кэш DNS распространения, который просто сохраняет разрешенные адреса к Вашему жесткому диску. На Linux существует pDNSd и DNSmasq. Обоих очень легко установить и рекомендовали постараться не разрешать адреса на Ваших серверах.