Building Clouds on Server 2012 R2

This session was a firehose of information on the design considerations when building your private cloud based on Server 2012 R2. There are ton of new features in WS2012 and R2, so this was a high level roadmap on how to figure out what you want to implement. Bottom line is that with WS2012 R2 and System Center 2012 R2, you have a full Cloud stack available. The 2012 releases built the foundation, but had some missing pieces. The R2 release rounds out those holes, and unifies the release schedule and simplifies the experience.

Introduction

• Windows Server 2012 is Cloud optimized
• Clouds are dynamic, multi-tenant, high scale, low cost, manageable and extensible
• Major new cloud enabling features in Server 2012, released last year
• 2012 built  a strong platform, but was not a full cloud solution

WS2012 R2 Improvements

• Live migration is much faster
• Live migration from 2012 servers
• Shared VHDX clustering
• Automated block-level storage tiering
• write-back cache
• Per-share auto-redirection to scale-out file servers
• Dedupe of VDI workloads
• iSCSI target VHDX support
• Multi-tenant site-to-site VPN gateway
• Hyper-V NAT and forwarding gateway
• vRSS
• NIC teaming dynamic-mode
• Desired state configuration
• Datacenter abstraction layer
• All aligned with System Center 2012 R2

Blueprint for a Cloud

• Build your managment stack
• Start provisioning compute nodes and storage
• Then you scale out as needed
• This is a cloud “stamp”
• Publish a self-service portal or APIs
• Add network gateways
• Add users

Infrastructure

• Think about: workloads, networking, storage, resiliency

Designing for the workload

• Cloud-aware stateless apps or stateful apps?
• IaaS cloud can support both but with different design considerations
• What are the workloads performance requirements
• 2 socket servers offer the best ROI
• Some workloads will benefit from hosts with SR-IOV
• Are workloads trusted? Think about level of isolation between workloads and QoS policies
• Keep it simple and manageable
• Can’t optimize a unified infrastructure for all possible workloads
• Standardize VMs, self-service based, managed to an SLA

Network Design

• Traffic isolation considerations (tenant generated traffic) and hoster/datacenter traffic (cluster traffic, storage, live migration mgtmt, etc.)
• Use physical isolation as needed, port ACLs, QoS & VM QoS
• Between tenants and datacenter: separate networks
• Between tenant VMs of different tenants: Hyper-V network virtualization & VM QoS
• Hardware offloads for NICs: HW QoS (DCB), RDMA, RSC, RSS, VMQ, IPsecTo, SR-IOV
• For storage, if using SMB 3.0, then the NIC would benefit from RDMA feature
• R2: can also use RDMA for Live Migration
• Look at RSS and RSC for the NIC which support management (Live Migration, management)
• Look at IPsecTO and VQM for VM guest NICs
• SR-IOV bypasses the extensible switch
• R2: vRSS (spreads NIC traffic load across multiple VM cores

Storage Design

• Hyper-V servers with internal SAS disks is a perfectly acceptable if you don’t need super high HA
• 2012: Can pool shared JBOD SAS array for some good HA
• Scaling options: Block based FC or iSCSI or file based (lower cost w/ high performance)
• Block based enables storage offload with ODX, and high IOPS

Resiliency Approaches

• Infrastructure – VMs not designed to handle failures, HA at server level, failover clustering as another layer of protection. High end servers, redundant power and apps.
• App-Level Resiliency – Cloud-aware apps can sustain failures without infrastructure dependency

WS2012 Representatitve Configurations

• Three different approaches are fully documented and validated by Microsoft:
• aka.ms/CloudBlog
• aka.ms/CloudConfigs
• aka.ms/CloudPowerShell

How do you deploy and configure?

• In 2012 it was a mixture of GUI and a lot of PowerShell
• With R2 and aligning with system center 2012 R2, it is much much easier
• “Physical computer profile” is new in SC2012R2 – Deploy Hyper-V to bare metal
• Demo showed provisioning a new scale out file server and creating a file share, all from a GUI

Scaling Considerations

• Compute (Hyper-V) cluster size
• Larger clusters improve overall efficiency
• Consider clustering across failure domains (e.g. cross-rack)
• Storage: Need JBODs with appropriate number of SAS interfaces

Management Stack Improvements In R2

• Provides a unified Powershell method to manage physical devices, such as switches
• MS created a logo program that vendors can certify against
• MS open sourced the OMI standard for anyone to use
• Desired State Configuration (DSC) MDC-B302 session

Windows Azure Pack

• Same self-service portal as Azure
• Common management experience
• Workload portability
• As future services are delivered in Azure, they will transfered into the private cloud
  

本文来自：http://www.derekseaman.com