[dns-operations] Docker

[彭勇华]

One of our DNS services is running on a virtual platform.
 The platform is built by virtual computing (KVM), virtual network (VxLAN
powered), and virtual storage (Ceph).
Not openstack, but the service developed by ourselves.

nameservers are:
ns1.yyclouds.com
ns2.yyclouds.com

regards.


2016-08-08 7:47 GMT+08:00 George Michaelson <ggm at apnic.net>:

> I too decided not to do a bunch of stuff (tcpdumps, timestamped packet
> analysis) from virtuals because I worried about isochrony. Then I noticed
> that even on bare metal, I could drop UDP in the kernel, get out of order
> presentation up into the user process, not log the query in bind..
>
> So I ran a job sending a million (queue image of evil person with pinkie
> to lips)  queries and checked tcpdump order on bare metal and on a virtual.
> It didn't seem to make any difference: the virtualized packet drivers these
> days really don't represent more overhead on you than many other things
> your kernel is doing.
>
> I am unconvinced that for most of us, the distinction matters. I am sure
> there are corner cases, but I think its very likely that time variance and
> lossage from virtuals compared to bare metal _for most people_ is below the
> noise threshold.
>
> If you put the virtual on some platform which is flogged, and has
> insufficient disk, memory, faulty VT logic I have no doubt this isn't true.
> Equally, if you run bare metal on a Raspberry Pi, I suspect your not
> getting the best response per packet.
>
> YMMV
>
> -G
>
> PS maybe there's a student project lurking in this? If it turns out there
> *is* a systematic variance by OS and {server type} and
> {jail,dock,VM,Xen,bare-metal,Kubernetes} which exceeded the variance from
> other sources, wouldn't it be nice to know?
>
>
> On 7 August 2016 at 21:36, Phil Regnauld <regnauld at nsrc.org> wrote:
>
>> sthaug at nethelp.no (sthaug) writes:
>> >
>> > Trying to avoid complexity and issues like the ones mentioned above is
>> > why I run my name servers on bare metal. YMMV.
>>
>>         You can run Docker in a VM, or on bare metal (most do).
>>
>>         The *assumption* is that you'll be running containerized services
>> on
>>         RFC1918 nets and NAT on the host. It's a different approach to
>> doing
>>         things, but nothing forbids one from doing it their way.
>>
>>         If you want best of both worlds, and still do process isolation
>> while
>>         benefiting from "the full stack" and no network shenanigans, you
>> could
>>         be using FreeBSD jails or Linux' LXD.
>>
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-operations
>> <https://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-operations>
>> mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160808/f7d28cf3/attachment.html>