Microsoft Azure Cloud Series – What is Cloud? – Part 1

Hi All, its Rob again and I decided to write a series on Azure Cloud.  Since Azure Stack is months away from GA, its good to understand Azure Cloud for a few reasons.  The API is the consistent across Azure Cloud and Azure Stack. And building a hybrid environment is the future for IT to use features like DR, Application Portability and Backup.

So, let’s start from the beginning and go over the fundamental terms.

What is Cloud? Simply put, it’s a large number of devices connected through wide communication network.

What are the benefits of Cloud?

  • Provide Services at much lower cost
  • Flexibility on technology that gives the customer a competitive advantage
  • Helps IT to be more efficient on operations
  • Pays as they go and for what they use
  • Move to OPEX model from CAPEX model
  • Faster deployment

Types of Clouds and Examples

Private

  • A private cloud is dedicated to the customer’s organization.
  • On-premises (their own data center) or in a partner’s hosting facility.
  • More control over the level of security, privacy, customization, and governance of your software and services.
  • More cost-effective data center operations using the customer’s existing investments in people and equipment.
  • Example: Customer needs dedicated resources and wants to restrict access to all content in the cloud

Public

  • The public cloud is where cloud services are provided in a virtualized environment.
  • Resources are available on demand.
  • Centralized operation and resource management are shared.
  • Customers can access the resource they need, and then only pay for what they use.
  • Many services are available that are ready to be accessed from any internet enabled device.
  • Example: Customer can share resources and wants to pay when they use the resource

Hybrid

  • A hybrid cloud is an integrated service utilizing on-premises resources, private clouds and public clouds.
  • Moving non-sensitive functions to the public cloud allows an organization to benefit from public cloud scalability while reducing the demands on a private cloud.
  • The availability of secure resources and scalable cost-effective public resources provides organizations with options.
  • Example: Customer has secure and non-secure data and they have made some investment in their own infrastructure and they want to use them

Industry Tends

Industrytrendsazure Cloud

As we look at the IT industry today, a number of important trends are changing the way software is being purchased, deployed and used in the organization.

Data Explosion

The volume of data in the workplace is exploding. According to IDC, digital data will grow more than 40x over the next decade. As more and more data is created digitally, we expect to see ever greater demands being placed on our data platforms to store, secure, process and manage these large volumes of data.

Consumerization of IT

Today we see an increasing trend toward the “consumerization” of IT—creating the demand for Web 2.0 experiences in the business environment. As consumers, we are accustomed to powerful user-friendly experiences, whether searching the Internet on a mobile device to find information instantly, or quickly accessing our personal financial data. In the workplace, however, we are often unable to answer even the most basic questions about our business. Increasingly, users demand business experiences that more closely mirror the convenience and ease of use in consumer life.

Private and Public Cloud

Cloud computing is changing the way data is accessed and processed, and it is creating whole new models for the way applications are delivered. According to IDC, Cloud services will account for 46% of net-new growth in overall IT spending. With private and public cloud infrastructure, organizations have an opportunity to reduce TCO dramatically as data volume increases. As we see an evolution toward greater use of private and public clouds, we see an increasing need for solutions that support hybrid cloud scenarios.

Azure at a Glance

azure-overview Cloud

So this picture, or at least the big blocks above, are how Microsoft thinks about the main capability buckets of their platform. As we go though this series, we will start to get more specific about these buckets (Compute, data, networks, and app services).

Well, I hope you enjoyed this brief introduction on Azure Cloud.  Stay tuned to the rest of the series. Next up, more fundamentals and use cases and then we dive into some fundamentals, like Azure Resource Manager.  Until next time, Rob

Microsoft SQL Server High Availability Options on Nutanix

To give credit, this content was taken from my buddy Mike McGhem’s blog and I added some more color to it, but hit content is right on.

In General, modern versions Microsoft SQL Server (MSSQL) supports several High Availability (HA) options at both the host and storage level.  For the purposes of this post I will only be addressing the HA options which leverage native Windows Server Failover Clustering (WSFC)  in some form.  SQL Server also provides transactional replication through the use of a publisher and subscriber model, which some consider an HA option, but that’s a topic (and debate) for another post with Mike McGhem.

Starting with MSSQL 2012, Microsoft introduced AlwaysOn which is a combination of some existing and new functionality.  Under the AlwaysOn umbrella falls two main options, Failover Cluster Instances (FCI) and Availability Groups (AAG).

Nutanix has long supported and recommended the use of AlwaysOn Availability Groups.  AAG leverages a combination of WSFC and native database level replication to create either an HA or disaster recovery solution between instances of MSSQL.  The instances of MSSQL leveraged to support the AAG can be either standalone or clustered (in the case of Nutanix these would be standalone instances today).   The following figure provides a logical overview of an AlwaysOn Availability Group.

Microsoft SQL High Availability

An AAG performs replication at the database level creating “primary” and one or more “secondary” database copies.  The secondary copies are replicated using  either synchronous or asynchronous commit mode, as specified by an administrator.  Asynchronous commit is intended more as a disaster recovery or reporting solution as it implies the potential for data loss.  So for HA scenarios as we’re discussing them here, we should assume synchronous commit.  Because database replication is used, shared storage is not required and each MSSQL instance within the AAG can use its own local devices.  Additional details on AlwaysOn Availability Groups can be found here: https://msdn.microsoft.com/en-us/library/hh510230.aspx

AAGs can take advantage of the secondary databases for the purpose of read-only transactions or for backup operations.  In the context of a scale-out architecture like Nutanix, leveraging multiple copies across hypervisor hosts for distributing these kinds of operations creates an excellent solution.

While AAGs are a great solution and fit nicely with the Nutanix architecture, they may not be a good fit or even possible for certain environments.  Some of the limiting factors for adopting AAGs can include:

  • Space utilization:  Because a secondary database copy is created additional storage space will be consumed.  Some administrators may prefer a single database copy where server HA is the primary use case.
  • Synchronous commit performance:  The synchronous replication of transactions (Insert/Update/Delete…) needed for AAG replication (in the context of an HA solution) do have a performance overhead.  Administrators of latency sensitive applications may prefer not to have the additional response time of waiting for transactions to be committed to multiple SQL instances.
  • Distributed Transactions:  Some applications perform distributed transactions across databases and MSSQL instances.  Microsoft does not support the use of distributed transactions with AAGs, and by extension application vendors will not support their software which utilize distributed transactions where AAGs are present.
  • SQL Server versions:  Some environments can simply not yet upgrade to SQL 2012 or higher.  Whether it be due to current business requirements or application requirements based on qualification, many administrators have to stick with SQL 2008 (and I hope not, but maybe even earlier versions) for the time being.

In the above cases MSSQL Failover Cluster Instances are likely the better solution.  FCI have long been used as the primary means for HA with MSSQL.  FCI can be leveraged with all current versions of MSSQL and relies on shared storage to support the MSSQL instances.  The following figure provides a logical overview of Failover Cluster Instances.

Microsoft SQL High Availability

The shared storage used can be block (LUN) based or, starting with MSSQL 2012, SMB (file) based.  In the case of LUN based shared storage, SCSI-3 persistent reservations are used to arbitrate ownership of the shared disk resources between nodes.  The MSSQL instance utilizing specific LUNs is made dependent against those disk resources.  Additional details on AlwaysOn Failover Cluster Instances can be found here:  https://msdn.microsoft.com/en-us/library/ms189134.aspx

Until very recently Nutanix has not supported MSSQL FCI within virtual machines, whether they reside on ESXi, Hyper-V or the Nutanix Acropolis Hypervisor (AHV).  But starting with the Nutanix 4.5 release (with technical preview support in posted 4.1.5 release), MSSQL FCI will be supported across all three of the aforementioned hypervisors.  Nutanix will support this form of clustering using iSCSI from within the virtual machines.  In essence Nutanix virtual disks (vdisks) which support SCSI-3 persistent reservations are created within a Nutanix container.  These vdisks will be presented directly to virtual machines as LUNs, leveraging the Nutanix Controller Virtual Machines (CVM) as iSCSI targets.  The virtual machines will utilize the Microsoft iSCSI initiator service and the Multipath I/O (MPIO) capabilities native to the Windows Operating System for connectivity and path failover.  An overview of this configuration can be seen in the following diagram.

Microsoft SQL High Availability

The association between virtual machine iSCSI initiators and the vdisks is managed via the concept of a Volume Group.  A volume group acts as a mapping to determine the virtual disks which can be accessed by one or multiple (in the case of clustering) iSCSI initiators.   Additional information on volume groups can be found under the Volumes API section of the Nutanix Bible: http://stevenpoitras.com/the-nutanix-bible/

Like AAG’s, MSSQL FCI may not be best suited for all environments.  Some of its drawback can include:

  • Shared storage complexity:  The configuration and maintenance of shared storage is often more complex to manage than standalone environments
  • Planned or unplanned downtime:  FCI can generally take more time to transition operation between cluster nodes than a similar AAG configuration.  Part of this downtime is to commit transactions which may have been in-flight prior to failover.  This can be somewhat mitigated with the recovery interval setting or using indirect checkpoints (https://msdn.microsoft.com/en-us/library/ms189573.aspx).
  • Separation of workloads:  AAG configurations can create multiple database copies across SQL instances for the purposes of distributed reporting or for backup offload.  An FCI cannot offer this functionality natively, although such configurations are possible via intelligent cloning methodologies that the Nutanix platform can offer.

As mentioned earlier it’s possible to configure both FCI and AAG as a part of the same solution.  So for example, if the HA capabilities of FCI are preferred, but the  replication capabilities of AAG are desired for the purposes of reporting, backup offload or disaster recovery, a blended configuration can be deployed.

With the support of shared storage clustering in 4.5, Nutanix can provide the full range of options necessary to support the broad number of use cases SQL Server can require.  Mike McGhem will have follow-on posts on his blog to detail how to configure volume group based clustering for Microsoft SQL Server.   Until next time, Rob.