The second day of Ignite i started of with a session on:
Azure Stack servicing and updating.
Updates for Azure stack consist of 2 packages or actually 3, but the third is different and not really clear how that is taking place because it will be the OEM vendor package and all vendors can take care of that in their own way. So the first package is for the OS updates for all the VM’s and hosts in the Azure Stack. The second package is about updating the resource providers in Azure stack. The Azure stack can be updated in a disconnected scenario as long as the bits are downloaded and uploaded in the blob storage through the Admin Portal.
Both are pretty big and not yet cumulative. Meaning that you have to run all the updates to get to the latest and you can’t skip an update or something. Updates will be every month and you should not supposed to fall behind more ten 3 months otherwise you will loss support and have to be current first.
Since the entire stack is locked you cannot login with RDP and go to Windows Update and click install updates. To take care of that Azure Stack has an Update Resource Provider. The resource provider gives an wizard in a set of blades to provide a destination to the update packages and install the update or schedule it.
Downtime:
During updating the admin portal goes down for about 10 minutes since it is only one VM. The customer portal how ever stays online because it’s redundant in the stack. The rest of the stack will also remain online as much as possible. The update process has a ton of checks and validations to update as graceful as possible, however if a VM does not live migrated the update process takes down a step in gracefulness. After live migration doesn’t work it will try a quick migrations, which means the VM is in save state for several seconds to a minute. Meaning no communication with that VM.
OEM Updates:
Every Azure Stack setup has a minimum of 4 hosts up to 12 max at the moment of writing. Every vendor add’s a 1u host that acts as OEM support server. The OEM support server is also called HLH. With this server the OEM vendor takes care of the Firmware and driver updates for the hosts but also the switch updates.
What more:
The PoC azure stack software has no update feature, because there is nowhere to place the VM’s if the host is restarting. Also will there be a maintenance window to schedule the update off work hours. Based on the size of the stack and the amount of the activity on the system the update process can last from 1,5 hour to 6 hours or more.
Azure stack delivery and Operations:
Planning and sizing:
Since Azure Stack is RTM and customers can order the systems there are 2 documents available to help in seizing and planning. The seizing sheet is more about how many storage do i need and what type, how many CPU Intense VM’s and or memory intense VM’s. This will be the Azure Stack Resource Calculator that will be launched some were in the end of October to help you out with the sizing. The planning sheet is more about how you want your current network infrastructure to interact with your own Stack. So for example what IP subnets do you want to use for certain networks, what your public IP space will be and what your current netwerk subnets are like. But also how to take care of identity, are you in connected or a disconnected scenario and much more.
Operating:
Like I mentioned before, the Azure stack system cannot be managed like every other VM or Host. It’s like an appliance, you have a portal and an cli interface (the admin portal and powershell) to manage it. This is because Microsoft and the OEM vendors are fully committed to make it as reliable and secure as possible and this is there approach to make it happen. Hardend by Default and Assume breach are key words during the session. You are able to do maintenance and trouble shooting through the portal and with Powershell and Just Enough Administration but it’s mainly to troubleshoot issue’s with Azure Stack and the integration with your own environment. For everything else you have to call Azure Stack Support.
Backup:
Backup of the entire stack was not part of this session, this was more about the stack it self. There are some valuable aspects that you need to backup, like the certificates, some vault keys and more. Backups will be placed in a remote file share outside of the Stack itself. Not to much info on that currently but there is some more in the Day 3 blog.
Monitor and Manage HyperConverged Infrastructures in Windows Server 2016
During Ignite 2017 i have seen a lot of sessions talking a lot about or touching project Honolulu. This sessions was mostly about Storage Spaces Direct and Honolulu. Since i already talked about Honolulu on this blog “Ignite 2017 @ Orlando Day 1” i am not repeating it and will stick to Storage Spaces possibilities with Honolulu.
So if you add your storage space direct cluster to honolulu you get a really rich set of monitoring feature.
With the dashboard you can view things like IOPS, Latency and Throughput real-time, over the past hour, days, weeks, months and even years! For the entire server or per disk. You can get info about the volumes and error messages for disks, volumes, nodes or the cluster.
You can also use Honolulu for the management, like creating new drives, expanding them or removing them. The wizard is full with options and the goals is to make it an almost all you need management tool. I like it!
New features:
One of the key features of Windows Server 2016 Redstone 3 or 1709 however you want to call it in terms of storage is ReFS and support for Deduplication. It’s one of the key features that other SAN vendors do offer but Windows since the coming of Deduplication on NTFS never supported. You were allowed to run DPM in a VM and VDI, but production workload VM’s were not supported. Until today is still not clear to me, in the session of Jeff Woolsey and Claus Joergenson they didn’t mention it.. I still need to get it clear. For DPM workloads it’s a great new future and removes the need to create a virtual DPM server just to use deduplication.
The other epic new feature for storage spaces is the support for Storage Class Memory, or SCM, or NVDIMM, or persistent memory or…. Well i think there are names enough for it. It comes down to this it’s epic fast! More on this in a later blog!
Beware the Mem size of the NVDimm is the total, not the size per NVDIMM, that is a bug in Honolulu that is part of the preview experience 🙂
Well that’s about it for my Day 2 of Ignite. Sorry the blog post are a bit later then I wanted them to be online 😉
Greetings
Pascal Slijkerman