DNS en tant que cache dissortingbué

Nous avons un cas d'utilisation pour cacher plus de 300 millions de pièces de ces données chacune avec une key unique.

Je sais que c'est peu orthodoxe, mais il a été suggéré à ma compagnie que DNS pourrait être utilisé comme un cache dissortingbué rapide pour des données de petite taille (<512 octets).

L'input DNS serait {Key}. {Module de key hashed} .mycompany.local.

c'est-à-dire U5333145311.1.memme.local

Nous ferions des requêtes au rythme de 5000 à 7500 par seconde de 10 à 15 servers.

Nous mettrons à jour chaque server DNS via les files de zone.

Comme je suis un programmeur, c'est tout nouveau pour moi

  1. Est-ce que cela est même possible?
  2. Quels sont les pièges?
  3. Comment puis-je dimensionner les servers DNS?

Merci

Mise à jour: datatables sont un tableau de 1 à 30 entiers (pas 512K désolé), donc c'est très petit. Mon CTO, issu des ops de réseau, comme cette solution, c'est parce qu'il s'agit d'un système connu et mature, qui a embedded la tolérance aux pannes et qu'il peut utiliser des op de réseau pour le gérer. Je suis très méfiant mais ouvert d'esprit.

11 Solutions collect form web for “DNS en tant que cache dissortingbué”

Le DNS est logique dans certains cas:

  • Données largement diffusées

    Par exemple, les lists noires DNS sont efficaces car l'infrastructure de caching existe déjà près des users (c'est-à-dire leur FAI), ou pour les gros users, ils peuvent facilement exécuter des logiciels personnalisés comme (rbldnsd). Cependant, il est préférable d'utiliser un protocole existant largement déployé.

  • Petites réponses (environ 500 octets max.)

    Les choses les plus intéressantes que les gens dissortingbuent via DNS sont petites et souvent même l'existence ou non de l'logging suffit (par exemple, un DNSBL signale qu'une adresse IP est mauvaise ou quelque chose qui indique que la sum de contrôle de ce file est "mauvaise").

    J'ai écrit ceci: https://dgl.cx/wikipedia-dns , et il pousse pratiquement la limite des tailles de réponse que vous pouvez faire en toute security dans DNS. Tout le monde ne met pas en œuvre ou ne supporte pas EDNS0 et, comme quelqu'un d'autre l'a dit une fois que vous êtes retombé sur TCP, le bénéfice d'être apasortingde disparaît.

Comme d'autres l'ont dit, il me semble que vous seriez mieux avec quelque chose comme memcached. Essayer de se contraindre à DNS semble stupide quand il est à usage interne. Si vous avez le contrôle sur le client, vous pouvez facilement faire un meilleur travail en cas de basculement et d'équilibrage de charge que le DNS lui-même peut faire.

Comme je suis le CTO du sceptique, j'aimerais faire de la couleur autour de la discussion.

Comme Gary l'a mentionné, l'application doit pouvoir publier un très grand manifeste. Le manifeste sera divisé en quelques (30-100) groupes. Chaque key sera en moyenne d'environ 55 octets, mais pourrait être beaucoup plus grande.

Quel que soit le produit que nous choisissons doit prendre en charge les éléments suivants:

1) Redondance complète et équilibrage de charge 2) Volume de transaction élevé (15k-20k lectures / sec) avec <500ms de time de réponse.

Les plus intéressants sont: 1) Structure hiérarchique 2) Enregistrement de l'expiration 3) Topologie auto-décrivant

Le DNS n'est apparu qu'après avoir pensé à utiliser UDP au lieu de TCP pour récupérer des données à partir d'un cache dissortingbué dans la memory. Naturellement, DNS est l'une des anciennes applications DNS.

DNS est connu pour prendre en charge les files de zone avec de très grandes quantités d'loggings. Par exemple .com. est un file de zone après tout (bien que réparti sur de nombreux servers à l'échelle mondiale). Il est également connu pour soutenir des niveaux très élevés de trafic.

Nous avons exécuté DNS à travers des tests préliminaires. Nous avons chargé un file de zone unique avec des loggings TXT 10M avec une quantité représentative de données. À partir d'un server différent sur le même réseau, nous avons ensuite effectué des tests de 300 000 requêtes de manière multi-threadée et obtenu environ 5 000 requêtes par seconde. Le server et le client ont à peine bougé pendant le test. Nous trouvons soit des goulets d'étranglement dans l'application de test elle-même, soit dans la stack de réseau sur le client.

Je suis insortinggué par le DNS car il supporte tout ce que je veux de manière native, et l'ai depuis de nombreuses années. Les caractéristiques que j'aime sont:

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 

Avec tout cela dit, le DNS semble être un outil bizarre à utiliser comme cache. Si elle finit par passer par la phase de sélection, nous l'utiliserions exclusivement uniquement sur le réseau local interne, et ce ne serait pas sur le même DNS que nos autres systèmes DNS internes ou externes. Une note est que nous pourrions vouloir partager datatables que nous stockons avec des partenaires tiers. DNS est une entité bien connue pour laquelle n'importe qui pourrait facilement requestr de recevoir des transferts de zone.

Merci de vos commentaires continus.

1 – probablement, mais pas recommandé
2 – Compétence de caching incomplète, instable, sans support partout
3 – aucune idée

Il existe essentiellement une solution prête à l'emploi en memcached: http://www.danga.com/memcached/

Ce n'est pas une mauvaise idée après tout.

S'il s'agit de performances, assurez-vous que la réponse correspond à un package udp (sinon, il returnnera à un tcp plus lent). Réglez les valeurs TTL judicieusement en fonction de la fréquence à laquelle vous souhaitez mettre à jour les loggings.

Il existe une manière (standard) de mettre à jour les loggings dynamicment, ce qui peut être bon si vous le faites à partir d'un programme.

si votre input dns est key.modulus, quelles sont datatables? l'adresse IP? est-ce que je manque quelque chose?

Utilisez memcached. C'est précisément pour ce but. Si vous mettez en cache des données, vous ne devriez pas vous inquiéter lorsque datatables seront effacées. Si un server disparaît, les clients continueront à utiliser les autres servers et ils seront simplement considérés comme une erreur de cache. Il existe des clients qui remanieront dans le cas d'un nœud défaillant. Je pense que last.fm a travaillé dessus.

Si vous avez besoin de données fiables, vous voudrez peut-être regarder quelque chose comme memcachedb, qui utilise un backend de berkerleyDB plutôt que de memory et fera une réplication entre deux noeuds.

  1. Est-ce que cela est même possible?
    Oui. Je vous suggère de regarder les loggings TXT pour contenir cette information

  2. Quels sont les pièges?
    Pas certain

  3. Comment puis-je dimensionner les servers DNS?
    Je ne suis pas sûr, mais autant que je le comprends, DNS est un service d'exigence assez faible en utilisant UDP pour traiter les requests et les réponses. En tant que tel, il appartient au client de déterminer s'il a répondu ou non et s'il vous plaît s'il n'a pas réussi .

La première indication selon laquelle votre DNS ne fonctionnait pas serait une épreuve sporadique de search complète.

Notez également que presque tous les systèmes informatiques qui effectuent ces requests mettront en cache le résultat pendant 30 minutes ou jusqu'à la valeur ttl des loggings si elle est inférieure à 30 minutes. Une manipulation minutieuse de ces valeurs serait nécessaire.


J'avais l'habitude d'héberger le menu de cantine sur un server de doigts, afin que tous puissent voir le menu des jours

<suce les oeufs> Je suggère également d'écrire votre programme avec des servers / groupes spécifiques à l'esprit et de ne pas countr sur le server DNS par défaut: O </ suck eggs>

De plus amples informations sur les conditions d'access / mise à jour seraient utiles pour rendre une opinion plus éclairée.

Par rapport au DNS lui-même, il est surtout optimisé pour des données relativement statiques qui changent rarement / lentement. En outre, pour la plupart, il est configuré pour fonctionner sur une quantité relativement faible de données à partir d'une perspective de server / zone unique. Il obtient l'évolutivité principalement de la caching intermédiaire (TTL) et de la nature de l'tree dissortingbué de la «database» mondiale par les servers de chaque organisation. Les servers DNS en double sont plus pour améliorer la disponibilité … et pas autant pour dissortingbuer la charge de travail (bien que cela puisse être le cas dans certaines applications).

Votre application semble pousser contre le grain de DNS est deux domaines:

  • Vos loggings ne sont pas si petits
  • Vous avez un grand nombre d'loggings à conserver

Le DNS pourrait être fait pour fonctionner dans votre application, mais je dirais clairement qu'il n'est pas optimisé pour cette affaire.

Alors que le DNS est idéal pour certaines choses, il n'est pas bon de stocker des valeurs de 512 Ko, même si vous la tranchez.

Si vous aviez 300 millions de points de reference beaucoup plus petits (disons, 1000 octets), le DNS (avec des packages de 1280 octets) pourrait être une bonne idée.

Le server autorisé PowerDNS pourrait être un excellent moyen de publier ces données, par exemple en utilisant le backend PIPE.

Mais pour datatables de 512 Ko, DNS ne correspond pas à votre facture.

Je n'ai jamais chargé le DNS testé dans cette mesure, mais je serais très prudent à propos de cette approche. Il est certainement peu orthodoxe et assez fou que cela pourrait fonctionner, mais l'approche est comme utiliser un marteau pour tourner une vis – sûr que vous pouvez le faire si vous configurez correctement, mais c'est le mauvais outil pour le travail.

Au pire, vous apporteriez le DNS de l'entreprise à ses genoux, et quelqu'un aurait l'obligation d'expliquer au PDG pourquoi il ne peut pas get son courrier électronique.

Je suggère un cache DNS de propagation qui enregistre simplement les adresses résolues sur votre disque dur. Sur linux il existe pDNSd et DNSmasq. Les deux sont très faciles à installer et à reorder pour éviter de résoudre les adresses sur vos servers.

  • DNSChanger Malware / Rogue DNS - "Internet Doomsday" 9 juillet
  • Éviter les timeouts d'attente DNS lorsqu'un server DNS fonctionne
  • creuser (et d'autres outils) seulement returnner les loggings A
  • Un autre domaine pointe vers mon server web
  • Le DNS ne s'inscrit pas dans les sites hors site
  • L'hôte de résolution est constamment lent
  • ufw bloking apt and dns
  • Comment le FQDN est-il déterminé?
  • Les servers RHEL sans access à Internet interrogent constamment DNS pour xmlrpc.rhn.redhat.com
  • Réseau Anycast - étapes requirejses pour implémenter un?
  • Copier le courrier électronique de Google Apps vers le script php du serveur
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.