System-NS from the inside

After the publication of the last article , in which there was information about how and why we came up with System-NS and what this service is like, questions began to pour in about our “ inner kitchen ”.

I want to say right away that we are not a competitor to Cloudflare in any way, so I see no reason to tell what we are better. Today, our service is aimed only at domain management. And unlike Yandex PDD, we provide Secondary and Dynamic DNS services.

Our task was to “use the maximum number of external modules” (in order to write less than your code). We spent a lot of time searching for suitable modules (with the necessary functionality and without bugs). In the process of this search, several of our young employees ceased to be firmly convinced of the “flawlessness” of open source projects. After screams and scuffles, we stopped at a bunch: ZF2 - Doctrine ODM - BjyAuthorize - ZfcUser.

A bit more about the components.
Frontend:

• Zend Framework (ZF) 2. Since earlier we used ZF for some projects, when starting work on System-NS we were infinitely happy about the release of ZF2, it turned out to be more convenient and productive than its predecessor.
• Doctrine ODM. A module that allows you to convert mongoDB documents to php objects. In fact, we selected this module in order to “see” what advantages it can give when working with mongoDB (we usually work through our own class / wrapper). The module turned out to be redundant and far from always convenient in operation.
• MongoDB. An excellent document-oriented database, we use it for almost all of our projects (the only minus of the database is the lack of transactions, but with proper persistence you can implement them).
• BjyAuthorize. The mechanism for restricting access to certain parts of the site is based on the user's “roles”.
• ZfcUser. The module for user management, contains ready-made (customizable) registration and authorization mechanisms. Perfectly compatible with Doctrine ODM and BjyAuthorize.
• Twitter Bootstrap A very nice set of CSS templates makes the task much easier with responsive design and layout in general.

Backend:

• A self-written DNS server (C ++) is a completely different story. I can’t spread very much, because the project is closed by the NDA. There is only one reason for writing it - performance. In our implementation, one core at 2 GHz (capable of serving up to 3-3.5 million requests per second), which corresponds to approximately 1.4 Gb of traffic dns (average). The same technology, with the permission of the owner, was used in the public service, but in a slightly truncated form. It has its own managed cache, but generally depends on an external data store.
• Memcached - used as a repository of the binary structure of domain zone records, instead of allocating memory in the dns daemon - for the sole purpose (see the next paragraph), although there were lengthy discussions about the fact that tcmalloc in dns itself would be faster, but decided not to load dns extra functionality
• A self-made daemon for replicating data on servers and saving snapshots to disk (C ++)

Physically, the service is located on five servers. Three of them (France, Ukraine, Russia) have a frontend. The other two servers (Norway, Czech Republic) are for replication. To balance the traffic, a fault tolerant balancer from Clustertech AS (Norway) was used - which is located on anycast segment.

Since the service is free - we do not yet see the need to launch our own anycast segment for it (although we have the opportunity), this is already from the category of expensive pleasure “for ourselves”, but it is possible that if there are a large number of comers, we will launch it.

Thank you for your attention and interest in our service.