Home Improvement Landscaping

The previous owner of our property believed in letting nature run its course entirely without human intervention. As a result our front yard had been a long outstanding project that we’d been afraid to tackle. In addition, we had some serious drainage problems that led to standing water in the driveway, and sump pumps that just dumped out into the front yard surface.

This year we decided to change all that and had For Garden’s Sake do some landscaping for us. In addition to dealing with the drainage, and overgrowth, we wanted them to fix the front yard that AT&T had dug up numerous times, as well as connect our awesome new front porch to the driveway in a nice looking way. I would say mission accomplished – but you can judge for yourself looking at the following before and after shots:

Before:

New paint, new porch, old landscaping.

After:

New landscaping and stonework leading up to the front porch.

It’s a huge improvement, and the galleries above should give you an idea of the overall project and progress for the entire front yard. We’re happy with the work and looking forward to watching all of these new native plants grow.

Best of all, there is no more standing water to worry about!

18 Years of Blogging

This blog has been alive in some form since 2002. As you can imagine a lot has changed in 18 years. The blog has moved physically from servers under desks, servers in closets, to finally virtual machines in the cloud. Even those VMs have changed AWS instance sizes and Ubuntu LTS versions over time. The blogging platform has also changed. I started this thing with a custom set of PHP pages that I wrote myself to pull entries from a MySQL database. I migrated to something called Serendipity for a while to get more features and then finally to WordPress. All the while the MySQL backend has been pretty much the same.

My photo sharing strategy has also changed. I moved from a directory of images, to Menalto Gallery, to Gallery3, and recently to Piwigo. Gallery3 has been unsupported for a VERY long time, but the nail in the coffin was that it required me to keep an older PHP version on the server. The switch to Piwigo allows me to ditch my Ubuntu PPAs for old PHP versions, and lets me use a photo sharing platform that receives updates, has themes, and works well on mobile.

The problem I face now is that in 18 years I’ve linked to a LOT of photos directly from the blog posts. In some places I wrote the HTML directly, in other places I inserted a link to an image using a WordPress block. In almost all of those cases I’m linking to Gallery3 album pages that no longer function. ALL of the older JPG images are still in the Gallery3 folders, taking up lots of space since they also exist in Piwigo.

I’m left with a few options:

  1. Go back and edit every single blog post that linked to images with the new Piwigo links.
    1. This may be easier if I create a LOT of permalinks inside Piwigo’s “category” structure for albums.
  2. Create some complicated mod_rewrite rule that intercepts the old links and sends to the new link.
    1. This will REQUIRE that I create a lot of permalinks in Piwigo.
  3. Put some boilerplate text at the top of every old post that points to the new high level photo gallery.
    1. Not great, because if I’ve learned anything – this won’t be the last platform migration I ever do.
  4. Do nothing. Leave the old links and images broken. Think only of now.
    1. This is tempting, but there is a lot of nostalgia in those old posts.

Wish me luck on this project. I still have some work to do, and next week I should have some time to focus on it.

Update 2020-04-29:

Crazy twist. I reinstalled a BUNCH of PHP packages from a custom PPA and replaced them with the default Ubuntu repo packages and now my old Gallery3 is working again. I suppose this gives me an option to keep old images on Gallery3, and new images in Piwigo. Still more thought needed here.

Home Improvement Porch Project

Kat bought our house around the same time that I bought my condo in 2014, before we even met! It’s an amazing property on a large wooded lot with nice privacy and set back a bit from the street in a quiet neighborhood.

The house had a great back deck with room for an outdoor dining table. Being in the woods and in NC means we had quite a few usable months for the porch – but our nemesis, the Aedes aegypti mosquito, made the outdoors pretty much a no-go-zone whenever it was above freezing for a few weeks.

Old Back Deck – Tree Removal In Progress

For years we were spraying for mosquitoes trying to keep the situation under control. We weren’t happy about having a service spray chemicals, but the mosquitoes were so thick in the air as to create a visible blood-sucking cloud.

We stopped the spray service when our next-door neighbor started raising bees and at that point we ceded control back to the mosquitoes. We needed to take more drastic (and expensive) measures to maintain an outdoor dining experience.

Last year, we decided we were going to replace the rotting front and rear decks with new long-lasting Trex Deck material and build a covered screened in section in the back. Along the way we cut down a number of trees, replaced the roof, and are nearing the final point where the back porch gets a screen added. Check out the album below to see the house as it changed over time.

Photos of our house project

We’re excited to use the new covered section as the temperatures warm up. We even plan on spending a few of our work from home days out there. We made sure there was PLENTY of power and that the WiFi signal covers the area!

There are still a few finishing touches we’re waiting on in addition to the screens. We need gutters and downspouts, to finish the paint on the outside siding, a few more lights and switches wired in, and some interior trim.

The next part of this crazy project is landscaping – but that may have to wait a while. What do you think of the new porch and the new look?

Ditching No-IP for DuckDNS

I’ve been using dynamic IP address services from no-ip.com for a long time to give a DNS name to my dynamic home IP. I remember having a no-ip.com address in college around the early 2000s for my dorm, then apartment, computer. I went through a hiatus after college where I managed my domain name to IP mappings manually for a few years (and my own Bind setup), until it seemed like the ISPs started giving me a new address monthly and the burden was too much. I also sold the hardware the DNS server ran on at some point during my moves.

I was happy to see that after over 10 years away, no-ip was still there, and got signed up right away. I have an Ubuntu Linux system as my home desktop (and server really) and was glad to find a client that seemed to run on it. It was a little finicky to get going and was a black box sort of client to install. That wasn’t a good sign to start.

Then came the emails. Oh my god, the emails. Every 30 days they want to make sure you’re still there, and have you verify your domain name. They give you a 1 week notice too, so this means every 21 days you’re getting an email to verify that you’re still there. If you don’t verify – they say they’ll delete your account. When you try to click the email and go to the site it’s VERY clear they’d rather have you sign up for a paid account. Every 21 days for a few years I got nagged until I couldn’t take it any more! They clearly told me that I should go somewhere else for my business if I didn’t want to pay.

This sort of things just bugs me.

At the Open Source conference All Things Open, someone mentioned DuckDNS and I decided to give it a try. It’s been a night and day difference from no-ip so far, for the better.

Here’s what I like:

  1. There is no black box app or script to install on my Linux box. They just use cron and wget.
  2. The instructions are clear and easy to copy and paste.
  3. No one has emailed me anything yet, and since they have ZERO marketing team, I’m assuming no one will.

If you want to get started I highly recommend them. If you’re running a Linux server it’s dead simple.

The whole idea is that you sign up on duckdns.org and get a unique key for your desired domain name. You take this unique key and their copy and paste script and run that every 5 minutes as a cron job.

Every 5 minutes, your server uses wget (called via cron) with the duckdns URL and key and their server figures out your external IP and updates it accordingly. It was ridiculously easy to get started and used systems I already know and love (bash and cron).

Let’s Encrypt – How do I Cron?

Let’s Encrypt was really easy to setup, but Cron was less so. I kept getting emails that the Let’s Encrypt renewal was failing:

2017-03-09 02:51:02,285:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/bbbburns.com.conf produced an unexpected error: The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(). Skipping.
1 renew failure(s), 0 parse failure(s)

I had a cron job setup with the absolute bare minimum:

crontab -e
56 02 * * * /usr/bin/letsencrypt renew >> /var/log/le-renew.log

When I ran
/usr/bin/letsencrypt renew
at the command line, everything worked just fine. I was like, “Oh – this must be some stupid cron thing that I used to know, but never remember.”

Turns out the problem was the cron environment PATH variable. Cron didn’t have access to /usr/sbin and apparently certbot was using that for access to the apache2 binary. The fix was to change the cron to the following:

56 02 * * * /root/le-renew.sh

Then create a script that runs the renewal after the PATH variable is set correctly:

cat /root/le-renew.sh
#!/bin/bash
#Automate the LE renewal process

#Need /usr/sbin for apache2
# https://github.com/certbot/certbot/issues/1833
export PATH=$PATH:/usr/sbin

#Renew the certs and log the results
/usr/bin/letsencrypt renew >> /var/log/le-renew.log

It was a good thing I put the link to the problem right in the script, or I never would have been able to find it again to write this blog.

NOW my renewal works absolutely fine. Problem solved. Thanks Cron.

Let’s Encrypt – Easy – Free – Awesome

I recently saw a news article about StartCom being on Mozilla and Google’s naughty list. Things looked bad, and my StartCom certs were up for renewal on the blog.

I have seen articles flying around about Let’s Encrypt for a while now. The idea seemed awesome, but the website seemed so light on technical instructions that I didn’t know if it would actually work. I wanted to know EXACTLY what lines it would propose to hack into my carefully manicured Apache configuration. And by carefully manicured, I mean “strung together with stuff I copied and pasted from stack overflow“.

I couldn’t find the information I really wanted – so I just JUMPED in and started installing things and running commands. 30 seconds later, I had a fully functioning cert on my site. I was blown away. It copied my existing non-ssl vhost config and created a new vhost with SSL enabled. All I had to do was enter my email address, select the vhost to enabled SSL for, and hit GO.

I had to put in a crontab entry myself to get the auto-renewal to work but that wasn’t so bad. I would hope they improve that in the future – but cron is no big deal.

I’m interested to see if everything works when my web certs expire 90 days from now! Crazy times. I used to do this and dread it once per year because the process was so manual. Now that it’s automated – I’ll get new certs while I’m sleeping. Woohoo.

Nutanix AHV Best Practices Guide

In my last blog post I talked about networking with Open vSwitch in the Nutanix hypervisor, AHV. Today I’m happy to announce the continuation of that initial post – the Nutanix AHV Best Practices Guide.

Nutanix  introduced the concept of AHV, based on the open source Linux KVM hypervisor. A new Nutanix node comes installed with AHV by default with no additional licensing required. It’s a full-featured virtualization solution that is ready to run VMs right out of the box. ESXi and Hyper-V are still great on Nutanix, but AHV should be seriously considered because it has a lot to offer, with all of KVMs rough edges rounded off.

Part of introducing a new hypervisor is describing all of the features, and then recommending some best practices for those features. In this blog post I wanted to give you a taste of the doc with some choice snippets to show you what this Best Practice Guide and AHV are all about.

Take a look at Magnus Andersson’s excellent blog post on terminology for some more detailed background on terms.

Acropolis Overview

Acropolis (one word) is the name of the overall project encompassing multiple hypervisors, the distributed storage fabric, and the app mobility fabric. The goal of the Acropolis project is to provide seamless invisible infrastructure whether your VMs exist in AWS, Hyper-V, ESXi, or the AHV. The sister project, Prism, provides the user interface to manage via GUI, CLI, or REST API.

AHV Overview

AHV is based on the open source KVM hypervisor, but is enhanced by all the other components of the Acropolis project. Conceptually, AHV has access to the Distributed Storage Fabric for storage, and the App Mobility Fabric powers the management plane for VM operations like scheduling, high availability, and live migration.

 

The same familiar Nutanix architecture exists, with a network of Controller Virtual Machines providing storage access to VMs. The CVM takes direct control of the underlying disks (SSD and HDD) with PCI passthrough, and exposes these disks to AHV via iSCSI (The blue dotted VM I/O line). The management layer is spread across all Nutanix nodes in the CVMs using the same web-scale principles of the storage layer. This means that by-default, a highly available VM management layer exists. No single point of failure anymore! No additional work to setup VM management redundancy – it just works that way.

AHV Networking Overview

Networking in AHV is provided by an Open vSwitch instance (OVS) running on each AHV host. The BPG doc has a comprehensive overview of the different components inside OVS and how they’re used. I’ll share a teaser diagram of the default network config after installation in a single AHV node.

AHV Networking Best Practices

Bridges, Bonds, and Ports – oh my. What you really want to know is “How do I plug this thing into my switches, setup my VLANs, and get the best possible load balancing. You’re in luck, because the Best Practice Guide covers the most common scenarios for creating different virtual switches and configuring load balancing.

Here’s a closer look at one possible networking configuration, where the 10gigabit adapters and 1gigabit adapters have been connected into separate OVS bridges. User VM2 has the ability to connect to multiple physically separate networks with this design to allow things like virtual firewalls.

After separating network traffic, the next thing is load balancing. Here’s a look at another possible load balancing method called active-slb. Not only does the BPG provide the configuration for this, but also the rationale. Maybe fault tolerance is important to you. Maybe active-active configuration with LACP is important. The BPG will cover the config and the best way to achieve your goals.

For information on VLAN configuration, check out the Best Practices Guide.

Other AHV Best Practices

This BPG isn’t just networking specific. The standard features you expect from a hypervisor are all covered.

  • VM Deployment
    • Leverage the fantastic aCLI, GUI, or REST API to deploy or clone VMs.
  • VM Data Protection
    • Backup up VMs with local or remote snapshots.
  • VM High Availability
    • During physical host failure, ensure that VMs are started elsewhere in the cluster.
  • Live Migration
    • Move running VMs around in the cluster.
  • CPU, Memory, and Disk Configuration
    • Add the right resources to machines as needed.
  • Resource Oversubscription
    • Rules for fitting the most VMs onto a running cluster for max efficiency.

Take a look at the AHV Best Practice Guide for information on all of these features and more. With this BPG in hand you can be up and running with AHV in your datacenter and get the most out of all the new features Nutanix has added.

Survivable UC – Avaya Aura and Nutanix Data Protection

I wanted to share a bit of cool “value add” today, as my sales and marketing guys would call it. This is just one of the things for Avaya Aura and UC in general that a Nutanix deployment can bring to the table.

Nutanix has the concept of Protection Domains and Metro Availability that have been covered in pretty great detail by some other Nutanix bloggers. Check out detailed articles here by Andre Leibovici, and here by Magnus Andersson for in depth info and configuration on Metro Availability.

Non-redundant Applications

In an Avaya Aura environment, most machines will be protected from failure at the application level. A hot standby VM will be running to take over operation in the event of primary machine failure such as with Session Manager and Communication Manager. In the following example we see that System Manager, AES, and a number of other service don’t have a hot standby. This might be because it’s too expensive resource wise, licensing wise, or the application demands don’t call for it.

1000-user_topology

If multiple Nutanix clusters are in place, we actually have two ways to protect these VMs at the Nutanix level.

Nutanix Protection Domains

First, let’s look at Protection Domains. With a Protection Domain, we configure a NDFS (Nutanix Distributed Filesystem) level snapshot that happens at a configurable interval. This snapshot is intelligently (with deduplication) replicated to another Nutanix cluster. It’s different than a vSphere snapshot because the Virtual Machine has no knowledge that a snapshot took place and no VMDK fragmentation is required. None of the standard warnings and drawbacks of running with snapshots apply here. This is a Nutanix metadata operation that can happen almost instantly.

We pick individual VMs to be part of the Protection Domain and replicate these to one or more sites.

In the event of a failure of a site or cluster, the VM can be restored at another site, because all of the files that make up the Virtual Machine (excluding memory) are preserved on the second Nutanix cluster.

ProtectionDomain

 

Nutanix Metro Availability

But I hear you saying, “Jason that’s great, but a snapshot taken at intervals is too slow. I can’t possibly miss any transactions. My UC servers are the most important thing in my Data Center. I need my replication interval to be ZERO.” This is where Metro Availability comes in.

Metro Availability is a synchronous write operation that happens between two Nutanix clusters. The requirements are:

  1. A new Nutanix container must be created for the Metro Availability protected machines.
  2. RTT latency between clusters must be less than 5 milliseconds (about 400 kilometers)

Since this write is synchronous, all disk write activity on a Metro Availability protected VM must be completed on both the local and the remote cluster before it’s acknowledged. This means all data writes are guaranteed to be protected in real time. The real-world limitation here is that every bit of distance between clusters adds latency to writes. If your application isn’t write-heavy you may be able to hit the max RTT limit without noticing any issues. If your application does nothing but write constantly to disk, 400km may need to be re-evaluated. Most UC machines are generally not disk intensive though. Lucky you!

MetroAvailability

In the previous image we have two Nutanix clusters separated by a metro ethernet link. The standalone applications like System Manager, Utility Services, Web License Manager, and Virtual Application Manager are being protected with Metro Availability.

In the even of Data Center 1 failure, all of the redundant applications will already be running in Data Center 2. The administrator can then either manually (or through a detection script) start the non-redundant VMs using the synchronous copies residing in Data Center 2.

Summary

Avaya Aura Applications are highly resilient and often provide the ability for multiple copies of each app to run simultaneously in different locations, but not all Aura apps work this way. With Nutanix and virtualization, administrators have even more flexibility to protect the non-redundant Aura apps using Protection Domains and Metro Availability.

These features present a consumer-friendly GUI for ease of operation, and also expose APIs so the whole process can be automated into an orchestration suite. These Nutanix features can provide peace of mind and real operational survivability on what would otherwise be very bad days for UC admins. Nutanix allows you to spend more time delivering service and less time scrambling to recover.

 

 

Virtualized Avaya Aura on Nutanix – In Progress

Explaining the Nutanix Distributed Filesystem

The Avaya Technology Forum in Orlando was a great success! Thanks to everyone who attended and showed interest in Nutanix by stopping at the booth. I met a lot of interested potential customers and partners and was also able to learn more about what people are virtualizing these days. There is nothing quite like asking people directly “What virtualization projects do you have coming up?”

Explaining the Nutanix Distributed Filesystem
Explaining the Nutanix Distributed Filesystem

After talking about Nutanix and what I do on the Solutions team, some key themes I heard repeated by attendees were:

“Wow, that’s really cool technology!”

and

“When will you have a document for Avaya Aura?”

The response to the first one is easy. Yeah, I think it’s really cool technology too. Nutanix will allow you to compress a traditional three tier architecture into just a few rack units. It gives you the benefits of locally attached fast flash storage AND the benefits of a shared storage pool. Customers can use this to save money, improve performance, and focus on their applications instead of their infrastructure. After you compress you also have the ability to scale up the number of nodes in the Nutanix cluster with no hard limit in place. Performance grows directly with cluster growth.

The second question is actually why I’m writing this blog today. When will the reference architecture for Avaya Aura on Nutanix be completed?

I’m in the research phase now because Avaya Aura is a monster of an application. It’s actually a set of dozens of different systems that all work together. Each system will have its own requirements for virtualization. Part of getting a reference architecture or best practices guide right is figuring out what each individual component requires to succeed.

Let’s give an example by looking at the Avaya Aura Virtual Environment overview doc. This list is the number of different OVAs that are available:

Avaya Aura® applications for VMware
• Avaya Aura® Communication Manager
• Avaya Aura® Session Manager
• Avaya Aura® System Manager
• Avaya Aura® Presence Services
• Avaya Aura® Application Enablement Services
• Avaya Aura® Agile Communication Environment (ACE)
• Avaya Aura® Messaging
• Communication Manager Messaging
• Avaya Virtual Application Manager
• Avaya Aura® Utility Services
• WebLM
• Secure Access Link
• Session Border Controller for Enterprise
• Avaya Aura Conferencing

Avaya Call Center on VMware (OVA files)
• Avaya Aura® Call Center Elite
• Elite Multichannel Feature Pack
• Avaya Aura® Experience Portal
• Call Management System

Each of the applications listed above is a separate OVA file available from Avaya. Each application has its own sizing, configuration, and redundancy guides. To deploy an Aura solution you can use some, or all of these components.

An Aura document on Nutanix is in the works, but it’s going to be a lot of WORK. I plan on focusing on just the core components at first and a few sample deployments to cover the majority of cases.

I’ve read every single Avaya Virtual Environment document and now just need to compile this information into an easy to digest Nutanix-centric format. In the meantime if you have Avaya Aura questions on Nutanix feel free to reach out to me @bbbburns

The great thing so far is that I don’t see any potential road blocks to deploying Aura on Nutanix. In fact at the ATF we performed a demo Aura deployment on a single Nutanix 3460 block (4 nodes). We demonstrated Nutanix node failure and Aura call survivability of the active calls and video conferences.

Part of the challenge of deploying any virtual application, especially real time applications, is that low-latency is KING. This was repeated over and over by all the Avaya Aura experts at the conference. Aura doesn’t use storage very heavily, but since it’s a real-time app the performance better be there when the app asks for it. All the war stories around virtualizing Aura dealt with oversubscribed hosts, oversubscribed storage, or contention for resources.

Deploying Aura on Nutanix is going to eliminate these concerns! Aura apps will ALWAYS have fast storage access. There will never be any contention because our architecture precludes it. I’m excited to work on projects like this because I know customers are going to save HUGE amounts of money while also gaining performance and reliability.

We really will change your approach to the data center.

Nutanix and UC – Part 3: Cisco UC on Nutanix

In the previous posts we covered an Introduction to Cisco UC and Nutanix as well as Cisco’s requirements for UC virtualization. To quickly summarize… Nutanix is a virtualization platform that provides compute and storage in a way that is fault tolerant and scalable. Cisco UC provides a VMware centric virtualized VoIP collaboration suite that allows clients on many devices to communicate. Cisco has many requirements before their UC suite can be deployed in a virtual environment and the Nutanix platform is a great way to satisfy these requirements.

In this post I’m going to cover the actual sizing and implementation details needed to design and deploy a real world Cisco UC system. This should help tie all the previous information together.

Cisco UC VM Sizing

Cisco UC VMs are deployed in a two part process. The first part is a downloaded OVA template and the second part is an installation ISO. The OVA determines the properties of the VM such as number of vCPUs, amount of RAM, and number and size of disks and creates an empty VM. The installation ISO then copies the relevant UC software into the newly created blank VM.

There are two ways to size Cisco UC VMs:

  1. Wing it from experience
  2. Use the Cisco Collaboration Sizing Tool

I really like “Option 1 – Wing it from experience” since the sizing calculator is pretty complicated and typically provides output that I could have predicted based on experience. “Option 2 – Collaboration Sizing Tool” is a requirement whenever you’re worried about load and need to be sure a design can meet customer requirements. Unfortunately the Sizing Tool can only be used by registered Cisco partners so for this blog post we’re just going to treat it as a black box.

Determine the following in your environment:

  • Number of Phones
  • Number of Lines Per Phone
  • Number of Busy Hour calls per line
  • Number of VM boxes
  • Number of Jabber IM clients
  • Number of Voice Gateways (SIP, MGCP, or H.323)
  • Redundancy Strategy (where is your failover, what does it look like?)

Put this information into the Collaboration Sizing Tool and BEHOLD the magic.

Let’s take an example where we have 1,000 users and we want 1:1 call processing redundancy. This means we need capacity for 1,000 phones on one CUCM call processor, and 1,000 phones on the failover system. We would also assume each user has 1 voicemail box, and one Jabber client.

This increases our total to 2,000 devices (1 phone and 1 Jabber per user) and 1,000 voicemail boxes.

Let’s assume that experience, the Cisco Sizing Tool, or our highly paid and trusted consultant tells us we need a certain number of VMs of a certain size to deploy this environment. The details are all Cisco UC specific and not really Nutanix specific so I’ll gloss over how we get to them.

We need a table with “just the facts” about our new VM environment:

Product VM Count vCPUs RAM HDD OVA
CUCM 2 1 4GB 80GB 2500 user
IM&P 2 1 2GB 80GB 1000 user
CUC 2 2 4GB 160GB 1000 user
CER 2 1 4GB 80GB 20000 user
PLM 1 1 4GB 50GB NA

The first column tells us the Cisco UC application. The second column tells us how many VMs of that application are needed. The rest of the columns are the details for each individual instance of a VM.

The DocWiki page referenced in the last article has details of all OVAs for all UC products. In the above example we are using a 2,500 user CUCM OVA. If you wanted to do a 10,000 user OVA file for each CUCM VM the stats can easily be found:

CUCM OVA Sizes

 

Visit the DocWiki link above for all stats on all products.

Reserving Space for Nutanix CVM

The Nutanix CVM runs on every hypervisor host in the cluster so it can present a virtual storage layer directly to the hypervisor using local and remote disks. By default it will use the following resources:

  • 8 vCPU (only 4 reserved)
    • Number of vCPUs actually used depends on system load
  • 16GB RAM
    • Increases if compression or deduplication are in use
  • Disk

In a node where we have 16 cores available this means we’d have 12 cores (16 – reserved 4) for all guest VMs such as Cisco UC. A cautious reading of Cisco’s requirements though would instruct us to be more careful with the math.

The Cisco docwiki page says “No CPU oversubscription for UC VMs” which means in theory we could be in an oversubscribed state if we provision the following in a 16 core node:

CVM x 4 vCPUs, UC VMs x 12 vCPUS = 16 total

It’s safer to provision:

CVM x 8 vCPUs, UC VMs x 8 vCPUs = 16 total

Even though it’s unlikely the CVM will ever use all 8 vCPUs.

Placing Cisco UC VMs

That’s a lot of text. Let’s look at a picture of how that placement works on a single node.

I’ve taken a single Nutanix node and reserved vCPU slots (on paper) for the VMs I want to run. Repeat this process for additional Nutanix nodes until all of your UC VMs have a place to live. Depending on the Nutanix system used you may have a different number of cores available. Consult the Nutanix hardware page for details about all of the available platforms. As new processors are released this page is sure to be updated.

*EDIT on 2015-10-23* Nutanix switched to a “Configure To Order” model and now many more processor core options are available, from 2×8 core all the way up to 2×18 core. This provides a lot of flexibility for sizing UC solutions.

The shaded section of the provisioned, but not reserved, CVM vCPU allocation is critical to sizing and VM placement. 4 vCPUs that will go unused unless the system is running at peak load. UC VMs are typically not IOPS intensive, so I would recommend running some other Non-Cisco workload in this free space. This allows you to get full efficiency from the Nutanix node while also following Cisco guidance.

Follow best practices on spreading important functions to multiple separate nodes in the cluster. This applies to ALL virtualization of UC. If we have one piece of hardware running our primary server for 1,000 users, it’s probably a good idea that the backup unit run on a DIFFERENT piece of hardware. In this case, another Nutanix node would be how we accomplished that.

Remember that at least 3 Nutanix nodes must be used to form a cluster. In the diagram above I’ve shown just a single node, but we’ll have at least two more nodes to place any other VMs we like following all the same rules. In a large Nutanix environment a cluster could contain MANY more nodes.

Installation Considerations

After the UC VM OVAs are deployed the next step is to actually perform the application installation. Without installation the VM is just an empty shell waiting for data to be written to the disk.

I’ll use an example CUCM install because it’s a good proxy for other UC applications.

Cisco_UC_Diagrams_shadow_ISO

The first Nutanix node has two CUCM servers and the second Nutanix node also has two CUCM servers. The installation ISO has to be read somehow by the virtual machine as it’s booted. In VMware we have a number of options available.

  • Read from a drive on the machine where vSphere Client is running
  • Read from a drive inserted into the ESXi Host
  • Read from an ISO located on a Datastore

DataStoreISO

When we select Datastore we can leverage a speedup feature of the Nutanix NDFS. If we put the CUCM ISO in the same NDFS container where the VM disk resides we can use Shadow Clones to make sure that the ISO is only ever read over the network once per Nutanix node.

In our previous example with two CUCM servers, the first CUCM server on the second node would be installed from Datastore. When the second CUCM installation was started on that same second node, it would read the ISO file from the local NDFS shadow clone copy.

 Rinse and Repeat

For all of the UC VMs and all Nutanix nodes the same process would be followed:

  1. Figure out how many and what size UC VMs are needed.
  2. Plan the placement of UC VMs on Nutanix nodes by counting cores and staggering important machines.
  3. Deploy the OVA templates according to your plan.
  4. Install the VMs from ISO making sure to use the Datastore option in vSphere.

In our next blog post we’ll  look at tools that can be used to make VM placement a bit easier and size Nutanix for different workloads.

Thanks for following along! Your comments are always welcome.