Tag Archives: Web-Scale

NPP Training series – Data Structure on Nutanix with Hyper-V

Posted on by
Reply

To continue NPP training series here is my next topic: Data Structure on Nutanix with Hyper-V
If you missed other parts of my series, check out links below:
Part 1 – NPP Training series – Nutanix Terminology
Part 2 – NPP Training series – Nutanix Terminology
Cluster Architecture with Hyper-V
To give credit due, most of the content was taken from Steve Poitras’s “Nutanix Bible” blog as his content is the most accurate and then I put a Hyper-V lean to it and have updated the graphics for Hyper-V.

Data Structure on Nutanix

The NDFS (Nutanix Distributed Filesystem) is composed of the following high-level structs:

Storage Pool

  • Key Role: Group of physical devices
  • Description: A storage pool is a group of physical storage devices including PCIe SSD (Solid State Drive), SSD, and HDD (Hard Disk Drive) devices for the cluster.  The storage pool can span multiple Nutanix nodes and is expanded as the cluster scales.  In most configurations only a single storage pool is leveraged.

Container

  • Key Role: Group of VMs/files
  • Description: A container is a logical segmentation of the Storage Pool and contains a group of VM (Virtual Machine) or files (vDisks).  Some configuration options (eg. (RF) Resiliency Factor) are configured at the container level, however are applied at the individual VM/file level.  Containers typically have a 1 to 1 mapping with a datastore (SMB Share(s)).

vDisk

  • Key Role: vDisk
  • Description: A vDisk is any file over 512KB on NDFS including VM hard disks.  vDisks are composed of extents which are grouped and stored on disk as an extent group.

Below we show how these map between NDFS and the Hyper-V:
SP_structure Data Structure

Extent

  • Key Role: Logically contiguous data
  • Description: A extent is a 1MB piece of logically contiguous data which consists of n number of contiguous blocks (varies depending on guest OS block size). Extents are written/read/modified on a sub-extent basis (aka slice) for granularity and efficiency.  An extent’s slice may be trimmed when moving into the cache depending on the amount of data being read/cached.

Extent Group

  • Key Role: Physically contiguous stored data
  • Description: A extent group is a 1MB or 4MB piece of physically contiguous stored data.  This data is stored as a file on the storage device owned by the CVM (Controller Virtual Machine).  Extents are dynamically distributed among extent groups to provide data striping across nodes/disks to improve performance.

Below we show how these structs relate between the various filesystems:
NDFS_DataLayout_Text Data StructureHere is another graphical representation of how these units are logically related:
NDFS_DataStructure3 Data StructureNext up, I/O Path Overview

Until next time, Rob…

Understanding Windows Azure Pack – Deployment Scenario’s on Nutanix – Part 2

Posted on by
Reply

To continue the Windows Azure Pack series, here is my next topic:  Deployment Scenario’s on Nutanix

If you missed part 1 – see link below
Part 1 – Understanding Windows Azure Pack

Windows Azure Pack – Deployment Scenario’s

Terminology

Ok, Let’s start with some terminology used when talking about WAP(Windows Azure Pack). Here are two key terms you need to know:

  • Administrator – Someone who deploys, configures and manages WAP and makes cloud services available to tenants.
  • Tenant – Someone who subscribes to and uses cloud services made available through WAP.

When WAP is deployed by a hoster (service provider) the administrator refers to IT staff at the hoster while the tenants are the customers to which the hoster is selling cloud services. And when WAP is deployed in an enterprise datacenter, the administrator will be your own IT department; the tenants in this case will be the other departments, divisions, or business units within your organization that want to take advantage of the cloud services your IT department is offering.

wap-admin-main Windows Azure Pack - Deployment Scenario'sAdmin Portal

 

wap-tenant-signin Windows Azure Pack - Deployment Scenario'sUser Signin Portal

wap-tenant-main Windows Azure Pack - Deployment Scenario'sUser Main Portal

Required components

WAP currently includes eight components. Two of these components are portals:

  • Management Portal for Administrators – A web-based portal that lets administrators configure and manage user accounts, resource clouds, tenant offers, and so on.
  • Management Portal for Tenants – A web-based self-service portal that lets tenants provision, monitor and manage the following cloud services: Web Sites, Virtual Machines, and Service Bus.

The self-service capabilities of the Management Portal for Tenants enables tenants to deploy and manage the cloud services they need when they need them without having to go through the slow procurement processes of the traditional approach to enterprise IT.
Authentication is another key feature of WAP to ensure that only properly authenticated administrators have access to the Management Portal for Administrators and only properly authenticated users have access to the Management Portal for Tenants. By default, the Management Portal for Administrators uses Windows authentication (Kerberos or NTLM) but you can optionally use Active Directory Federation Services (ADFS) for authentication purposes. The Management Portal for Tenants on the other hand uses the ASP.NET Membership Provider for authentication purposes. WAP includes two authentication sites, an Admin Authentication Site and a Tenant Authentication Site, for these purposes.
WAP also includes components that provide the following application programming interfaces (APIs):

  • Windows Azure Pack Admin API – Enables administration tasks to be performed using the Management Portal for Administrators and Windows PowerShell.
  • Windows Azure Pack Tenant API – Enables tenant-specific tasks to be performed using the Management Portal for Tenants and Windows PowerShell.
  • Windows Azure Pack Tenant Public API – Provides additional tenant-specific functionality primarily for hosting provider environments.

All of the above components are required in any WAP deployment.

Optional components

The following components of WAP may be deployed in order to offer additional forms of cloud services and other resources to tenants:

  • Web Sites – Provides you with a managed web environment you can use to create new websites or migrate your existing business website into the cloud.
  • Virtual Machines – Provides you with a general-purpose computing environment that lets you create, deploy, and manage virtual machines running in the Windows Azure cloud.
  • Service Bus – Allows you to keep your apps connected across your private cloud environment and the Windows Azure public cloud.
  • Automation and Extensibility – Allows you to automate and integrate custom services into your services framework using runbooks.
  • SQL and MySQL – Allows you to provision Microsoft SQL and MySQL databases for tenants to use.

Windows Azure Pack – Deployment Scenario’s

There are two basic deployment scenarios for WAP:

  • Express architecture – Recommended for proof of concept testing only.
  • Distributed architecture – Recommended for production environments.

In addition, the distributed architecture can be implemented in various ways depending on the scale and degree of availability needed. Let’s briefly examine each of these scenarios.

Express architecture

In an express deployment of Windows Azure Pack, you install all of the required components on a single server and any optional components needed on one or more additional servers. This is the deployment I will be doing in the next part of the series. Specifically, the following required components must all be installed on your first server:

  • Windows Azure Pack Admin API
  • Windows Azure Pack Tenant API
  • Windows Azure Pack Tenant Public API
  • Admin Authentication Site
  • Tenant Authentication Site
  • Management Portal for Administrators
  • Management Portal for Tenants

In addition, your first server must host the SQL Management Database used by the required components. This means you must install a required version of Microsoft SQL Server on the first server.

Distributed architecture

In a distributed deployment of WAP, you spread out the required components across multiple servers. There are many ways you can do this, but the following recommendations should generally be adhered to in order to ensure optional performance and supportability for your deployment:

  1. Install a management portal and its corresponding authentication site on the same server. For example, install the Management Portal for Administrators and the Admin Authentication Site on the same server.
  2. If you will be providing cloud services to tenants over the public Internet, install the following components on the same public-facing server:
  • Management Portal for Tenants
  • Tenant Authentication Site
  • Windows Azure Pack Tenant Public API
  1. If Active Directory Domain Services (ADDS) is to be used for authentication purposes, install it on a separate identity server.
  2. If Active Directory Federation Services (ADFS) is to be used for authentication purposes, install it on a separate identity server along with an ADFS
  3. For greater scalability and high availability in large deployments, install the SQL Management Database on a separate failover cluster. In addition, use failover clustering for your public-facing servers and for the servers hosting your other required components.
  4. For even higher scalability, install each required component on a separate failover cluster and the SQL Management Database on another failover cluster. In other words, use eight failover clusters to deploy the seven required components plus the SQL Management Database. Check out Nutanix Best Practices guide for deploying SQL

In the next blog post in this series, we will begin our walk-through of installing and configuring WAP. I will focus primarily on the express deployment scenario in this series along with two types of cloud services: Virtual Machines and SQL Databases…………..Let’s build a cloud……

Until next time, Rob…

NPP Training series – Cluster Components with Hyper-V

Posted on by
Reply

To continue NPP training series here is my next topic: Cluster Components

If you missed other parts of my series, check out links below:
Part 1 – NPP Training series – Nutanix Terminology
Part 2 – NPP Training series – Nutanix Terminology
Cluster Architecture with Hyper-V
Data Structure on Nutanix with Hyper-V
I/O Path Overview

To give credit, most of the content was taken from Steve Poitras’s “Nutanix Bible” blog as his content is the most accurate and then I put a Hyper-V lean to it.

Cluster Components

The Nutanix platform is composed of the following high-level components:

NDFS_Cluster Components

Cassandra

  • Key Role: Distributed metadata store
  • Description: Cassandra stores and manages all of the cluster metadata in a distributed ring like manner based upon a heavily modified Apache Cassandra.  The Paxos algorithm is utilized to enforce strict consistency.  This service runs on every node in the cluster.  Cassandra is accessed via an interface called Medusa.

Medusa

  • Key Role: Abstraction layer
  • Description: Medusa is the Nutanix abstraction layer that sits in front of the cluster’s distributed metadata database, which is managed by Cassandra..

Zookeeper

  • Key Role: Cluster configuration manager
  • Description: Zeus stores all of the cluster configuration including hosts, IPs, state, etc. and is based upon Apache Zookeeper.  This service runs on three nodes in the cluster, one of which is elected as a leader.  The leader receives all requests and forwards them to the peers.  If the leader fails to respond a new leader is automatically elected.   Zookeeper is accessed via an interface called Zeus.

Zeus

  • Key Role:  Library interface
  • Description: Zeus is the Nutanix library interface that all other components use to access the cluster configuration, such as IP addresses. Currently implemented using Zookeeper, Zeus is responsible for critical, cluster-wide data such as cluster configuration and leadership locks.

Stargate

  • Key Role: Data I/O manager
  • Description: Stargate is responsible for all data management and I/O operations and is the main interface from Hyper-V (via SMB 3.0).  This service runs on every node in the cluster in order to serve localized I/O.

Curator

  • Key Role: Map reduce cluster management and cleanup
  • Description: Curator is responsible for managing and distributing tasks throughout the cluster including disk balancing, proactive scrubbing, and many more items.  Curator runs on every node and is controlled by an elected Curator Master who is responsible for the task and job delegation.  There are two scan types for Curator, a full scan which occurs around every 6 hours and a partial scan which occurs every hour.

Prism

  • Key Role: UI and API
  • Description: Prism is the management gateway for component and administrators to configure and monitor the Nutanix cluster.  This includes Ncli, the HTML5 UI and REST API.  Prism runs on every node in the cluster and uses an elected leader like all components in the cluster.

prism1 Cluster Components prism2 Cluster Components

Genesis

  • Key Role: Cluster component & service manager
  • Description:  Genesis is a process which runs on each node and is responsible for any services interactions (start/stop/etc.) as well as for the initial configuration. Genesis is a process which runs independently of the cluster and does not require the cluster to be configured/running.  The only requirement for genesis to be running is that Zookeeper is up and running.  The cluster_init and cluster_status pages are displayed by the genesis process.

Chronos

  • Key Role: Job and Task scheduler
  • Description: Chronos is responsible for taking the jobs and tasks resulting from a Curator scan and scheduling/throttling tasks among nodes.  Chronos runs on every node and is controlled by an elected Chronos Master who is responsible for the task and job delegation and runs on the same node as the Curator Master.

Cerebro

  • Key Role: Replication/DR manager
  • Description: Cerebro is responsible for the replication and DR capabilities of DFS(Distributed Storage Fabric).  This includes the scheduling of snapshots, the replication to remote sites, and the site migration/failover.  Cerebro runs on every node in the Nutanix cluster and all nodes participate in replication to remote clusters/sites.

Pithos

  • Key Role: vDisk configuration manager
  • Description: Pithos is responsible for vDisk (DFS file) configuration data.  Pithos runs on every node and is built on top of Cassandra.

Next up, Data Structures which comprises high level structs for Nutanix Distributed Filesystem

Until next time, Rob….

Microsoft Ignite 2015 – Week in Review…

Gallery

Posted on by

Microsoft Ignite 2015 – Week in Review Well, it was a great show and finally recovering with some sleep under my belt.  Here we go…  Microsoft Ignite 2015 is where I had a chance to meet and talk with the industry leaders … Continue reading →

Nutanix Community Edition – Deploying and Configuring – Part 1

Posted on by
Reply

nutanix-community-edition_w_500Another very exciting announcement was Nutanix Community Edition (CE) on June 9th, 2015 at our Inaugural .NEXT conference. So, what is it?…..Our website describes it the best “Community Edition is a 100% software solution enabling technology enthusiasts to easily evaluate the latest Hyperconvergence technology at zero cost.”

In other words, you can use your own hardware to test out Nutanix.  Very cool.  This is great for building a lab and just gaining understanding of Hyperconvergence hands on.
Nutanix is offering a hardware compatibility list (HCL) to users that includes the minimum requirements to run the software; essentially, any standard x86 server can be used….

And to quote our CEO and co-founder Dheeraj Pandey:

“From our very first software release in 2012, Nutanix has been dedicated to open architectures and technologies, offering unprecedented customer choice and flexibility,” “Community Edition is the next step in democratizing HyperConverged infrastructure technology, enabling anyone to experience the transformative benefits of our software. Only by eliminating the requirement for proprietary hardware and embracing off-the-shelf platforms can the next revolution of datacenter technologies be fully realized.”

As the name implies, the support for the CE will come from the community through Nutanix’s NEXT online portal. Users will be able to log in, ask questions and get answers from the community.

CE also allow you to also check our new Acropolis hypervisor based on KVM.  Check out Josh Odger’s Blog to learn more about Acropolis.

Join the beta…And don’t forget my NPP training series that helps you with all the concepts around Hyperconvergence.

Currently, I am getting started with Nutanix CE installation and will be posting my experiences in a later blog post with how I build my Nutanix Lab @ Home. 🙂

Until next time….Rob

NPP Training series – Nutanix Terminology – Part 2

Posted on by
2

I was asked  “What does Web-Scale Mean?” at the end of my last post.

If you missed part 1, check link below:
Part 1 – NPP Training series – Nutanix Terminology

Continue reading →

NPP Training Series – Nutanix Terminology – Part 1

Posted on by
1

I started with Nutanix about 1 month ago and concurrently began my Nutanix training which entails going through the NPP (Nutanix Platform Professional) training course. I will be posting a series of blog posts on my learning track with Nutanix and will eventually tie it all together with the Microsoft Stack. My track commenced about 2 weeks ago and I have keep detailed notes on my learning progress. My plan is to post every few days in a multi-part series.

Continue reading →