none
Missing features to make this genuinly useable? RRS feed

  • Question

  • Hi there,

    I have been flowing development of windows containers and SQL 2016 with interest. And I have been trying things as they have become available. but I have a few roadmap related questions.

    I wonder if consideration / work has already gone in to these points, but it is certainly what I would like to see before I consider moving my current C# / Linux / mono / Docker deployment to windows containers.

    As it stands I am able to create a windows container swarm, however, I am unable to solve some key problems.

    Currently, I am using Ceph+Flocker to manage the volumes for my data containers. This ensure that if swarm brings up a container on a different server, the existing volume can be re-used. I am able to decouple the service form the storage of any given host.  Will there be a way to use the Software Defined Storage for the same purpose?

    I am also using Entity Framework and a PostgreSQL cluster. If I move to windows containers, I would like to use SQL 2016. I have already got a single instance of SQL 2016 working fine in a container, however, I have not yet clustered it. From what I read, SQL 2016 depends upon in-build windows clustering technology, with non-windows based clustering deprecated. How will this work in windows containers? do we cluster the containers?

    Finally, key elements of my architecture rely on the ability to dynamically reload nginx proxy and DNS. Specifically I am using the ahmet/wagl image for DNS that listens to the swarm master for changes, and registers container with DNS. It would be nice to see these kinds of use cases supported in IIS and DNS.

    Sorry it's not so much a question, and more feedback.

    Monday, May 9, 2016 10:44 AM

All replies

  • Thank you for the feedback - this type of feedback really helps us understand your uses cases and focus or development.

    We do expect volume plugins (I.e Flocker) to work with Windows, there will be some work depending on the implementation but the overall process should be similar. Windows Failover Clustering isn't going to be supported in Windows containers at least for 2016 - there are a lot of dependencies on storage and drivers that are counter to some of the portability goals of containers (at least as currently implemented).

    In terms of DNS - we're looking a lot at the DNS models in swarm/compose (were the containers register with DNS) but the same method that WAQL uses should also work as swarm is just a cross compile.


    -Taylor

    Sunday, May 22, 2016 9:14 PM
  • Thanks Taylor, you are very welcome, it is the reason I gave you the feedback in the first place.

    Good to hear about volume storage. Is there any kind of pre-release where I could take a look at this? I have not tried the latest TP yet, is there anything in there yet for distributed volumes?

    Regarding the windows clustering, I too felt it kind of goes against the idea of containers. My concern around this is less about windows clustering, and more about how to set up HA SQL server in containers. According to this page: https://msdn.microsoft.com/en-us/library/ms190202.aspx, database mirroring is being deprecated leaving only the AlwaysOn or Log shipping options. And if containers do not support windows clustering, then the only option left is log shipping, and that concerns me. This seems even more counter intuitive given the news from Build that MS SQL is coming to Linux. Is it coming with no clustering support? We won't be using windows server failover clustering on Linux now will we! And this is all just for High availability, I haven't even started looking at scale out yet. To me, scaling SQL is the obvious use case for windows containers.

    In my CoreCLR/mono microservice world, running SQL in a container is the only real driving force behind adopting windows containers, given that all my code is already running in Docker containers on Linux. Entity framework supports PostgreSQL/MySQL, both of which can be scaled easily in Docker containers, as can MongoDB. If SQL/Windows containers are going to compete with that, it seems MS need to be doing a bit more joined up thinking.

    The other important feature for me is that both windows and nix machines can exist in the same swarm. Currently, if I join a windows swarm node, it will not report all of its details correctly to the swarm manager (on Linux), so containers never get scheduled for the windows box. My intention is to tag the daemons with platform=win or platform=nix labels, and reference the labels from my compose files. That way I can easily move my CoreCLR and Mono services to which ever node/platform I like (for best performance of whatever) and still support dependencies such as databases running in either platform.

    Other stuff I would like to see running in windows containers included RabbitMQ nodes, container, host and RabbitMQ metrics exporters for Prometheus/PromDash, IIS as a proxy/loadbalancer, and windows DNS.

    I hope it doesn't sound to much like I am moaning, I really appreciate all the work that has gone into this, and I am so pleased to see MS heading in this direction. Really looking forward to getting some of this stuff into my platform!

    Thanks again

    Thursday, May 26, 2016 2:00 PM