Posted: November 28, 2014 | Author: VirtuallyMikeB | Filed under: NetApp, PowerShell / PowerCLI, Storage | Tags: autogrow, autosize, fractional reserve, lun, lun offline, luns, NetApp, netapp best practices, netapp powershell, netapp powershell toolkit, netapp toolkit, no space, nospc, powershell toolkit, snap autodelete, snapshot autodelete, vol best practices, volume, volume best practices |
Happy Day-after Thanksgiving dear readers! I hope everyone is as satisfyingly full on food, friends, and family as I am. As an early gift to myself, I’m writing a PowerShell script that utilizes NetApp’s PowerShell Toolkit. The script will help me quickly determine current volume and LUN settings so I can see what LUNs are at risk of going offline due to out of space conditions. In scripting tradition, I couldn’t find anything online that did exactly what I wanted so I rolled my own!
Here’s what the output looks like. The column names are abbreviated because I expect to have several more columns. The abbreviations are, Volume Thin Provisioning, Fractional Reserve, Snapshots, Volume AutoGrow, Snapshot AutoDelete.
Read the rest of this entry »
Posted: November 17, 2014 | Author: VirtuallyMikeB | Filed under: Cisco UCS, SRM | Tags: cisco ucs, ucs, vr, vsphere replication |
I was recently designing a vSphere Replication and SRM solution for a client and I stated we would use static routes on the ESXi hosts. When asked why, I was able to 1. discuss why the default gateway on the management network wouldn’t work and 2. present some options as to how we could separate the vSphere Replication traffic in a way that would allow flexibility in throttling its bandwidth usage.
You won’t see listed here Network I/O Control because this particular client didn’t have Enterprise Plus licensing and therefore wasn’t using a vDS. In addition, this client was using a fibre channel SAN on top of Cisco UCS with only a single VIC in his blades. This configuration doesn’t work well with NIOC because it doesn’t take into account FC traffic which is sharing bandwidth with all the Ethernet traffic NIOC *is* managing.
Read the rest of this entry »
Posted: November 10, 2014 | Author: VirtuallyMikeB | Filed under: SQL Server, SRM, VMware, Windows | Tags: 2008, 2012, disaster recovery, dr, options, sql dr, sql server dr, srm, vsphere replication |
While SQL Server is not one of my core competencies, I have worked with clients to protect their business critical applications in a VMware environment that utilizes SRM for DR. These options rely on either Native SQL protection schemes or VMware options like SRM or vSphere Replication. There are, of course, many 3rd party options, as well, depending on the storage array in use, which I won’t go into here. While there are usually good, better, and best options, the idea I’d like to get across here is that there are many ways to protect SQL Server. They can all be used at the same time even. I’ve had clients that had so many SQL Servers, this is essentially what they did – they had to pick and choose how to protect each based on their relative importance.
SQL Server 2012 AlwaysOn Availability Groups
For the most critical SQL Servers, the image below shows the high-level view of what my clients have used with success. For server failures at the Primary Data Center, there are multiple SQL Servers. AAGs can use both an Active-Active model and an Active-Passive model with regard to where the active database resides. Continuing with the Primary Site, Node 1 can host both an Active and a Passive database. Node 2 can host an Active and Passive database, as well, working with Node 1 to perform synchronous replication. Through asynchronous replication, both databases can be replicated to the DR site, where only Passive copies reside. In the event Site A completely fails, Node 3 can be brought online.
Read the rest of this entry »
Posted: November 7, 2014 | Author: VirtuallyMikeB | Filed under: Book Reviews, NetApp, Storage | Tags: netapp book;vcshb;vcenter server heartbeat;author for hire |
I had the good fortune this past summer to be presented the opportunity to write a book. I had been reviewing VMware-related books for some time already when a publishing company reached out with an offer. I eagerly accepted and began writing in June. In less than a month, I was done. Not because I had finished setting pen to paper, but because my topic, vCenter Server Heartbeat, was put out to pasture…then shot. VMware put the focus of my road to virtualization glory and stardom on its End-of-Life list and stopped selling vCSHB on July 2nd, 2014. Soon after, my publishing company killed the book, too.
I was disappointed I wasn’t able to finish. What I did complete, though, I’d like to share, with the hope that maybe someone out there is looking for an author and likes my work. Actually, you don’t even have to like my work to make an offer. I like the idea of writing a book, but articles work well, too, or even training materials. I would most like to write about NetApp – maybe an introduction or a design, installation, and configuration guide. They have plenty of products that could be written about and besides vendor documentation, there’s not a lot of info in book form. I especially like the idea of third-party training videos – I know there are several for EMC, but none for NetApp. I think it’s time to change that. My other interests include VMware and Cisco UCS.
Chapter 1
Chapter 2 (never finished)
Posted: November 3, 2014 | Author: VirtuallyMikeB | Filed under: NetApp, Storage | Tags: igroup, initiator, initiator group, luns, NetApp |
I’m often asked by my clients the best way to configure NetApp igroups when connecting to VMware VMFS LUNs, especially after I deploy a new system for them and I’m training them on their use. I appreciate the question because it means someone’s actually thinking through why something is configured the way it is rather than just throwing something together.
The Problem
So this is what I see a lot of out in the field. Single igroups are created with multiple initiators from multiple hosts. This can be a problem, though, as I’ll show you. Functionally, this configuration will work – each host will be able to see each LUN, all things being equal. The problem arises when you want to either 1. remove a host from the igroup or 2. stop presenting a LUN to only a subset of hosts.
Read the rest of this entry »
