Pages

Search

Tuesday, September 2, 2014

My Road to MCSA Series | 70-410 Edition, PT. 3 - Storage Virtualization

With just a little over two weeks in so far, I'm pretty confident that I understand most if not all of domain 1, Installing and Configuring. I wanted to check in and post a quick update on my progress.

For additional hands-on practice as I'm reading, I setup one of my lab machines to simulate Storage Pools and Storage Spaces in Windows Server 2012 R2.

To set up the lab, I first created six 5 GB VHDs on my lab host machine using computer management, numbered VHD1-6 to represent six physical disks that I would attach to my VirtualBox guest VM. Once the six drives were created, I opened the settings to my VirtualBox guest VM and added a SAS adapter. Windows Server 2012 R2 seemed to have no problems picking up on these new VHDs posing as physical disks.
Remote Desktop View of Storage Pool Available Physical Disks
From this point, I created my first Storage Space named "SVR-Lab2_Pool1" and added all available physical disks to the pool accepting defaults using the wizard. I now have a 25 GB Storage Space created from the Storage Pool consisting of the six physical drives. I was easily able to create virtual disks from here to quickly provision storage which I plan to use later for practice with file and folder permissions.

Just to toss in some PowerShell, I also used PowerShell ISE to create a Storage Pool using built in cmdlets.

One term that was used that initially tripped me up was primordial. At first I was having trouble understanding this term fully but found a really great explanation here. With the further explanation and visual aids, the easiest way for me to remember what primordial means is to think of JBOD (just a bunch of disks). Being a huge fan of virtualization anyways, this part of the lab excercise has been enjoyable and fairly easy once I understood it's use.

That's all I have for now and I'll continue to post more as I progress.


Avoiding the Unnecessary: The Importance of Testing Before Deploying


Testing a solution before deploying the solution helps you avoid the unnecessary pain and embarrassment of dealing with a post-implementation failure. Thankfully I learned this early in my career. This sage advice was passed down to me by a more senior co-worker. I was struggling to understand why my hastily constructed plan wasn't working how I imagined. My fellow IT Pro pulled me aside and asked,

“Bill, did you test this solution before deploying it?”

N00b mistake. I became red-faced and quite embarrassed as I admitted that I had not. The senior engineer and I had a talk about the importance of testing solutions before putting them into production. I've kept these valuable lessons in mind ever since.
“Bill, remember the bad 7 Ps. Piss Poor Planning Promotes Piss Poor Performance.” and they weren't done, “But that’s not all! Also remember the good 7 Ps. Proper Planning and Practice Prevents Piss Poor Performance.”

Powerful words, easy to remember, full of truth.

I’ve seen my fair share of the bad 7 Ps. The first 3 Ps (Piss Poor Planning) are often the result of an IT Pro’s bravado or machismo when working on projects. This can be witnessed in the verbal and nonverbal actions with both new and seasoned IT Pros. Trying to impress the boss, team members or even the customer by being aggressive about “being right” will often lead to these three Ps becoming apparent when deploying an untested solution into production. That’s when the last 4 Ps (Promotes Piss Poor Performance) typically are noticed by the boss, customer, or team members. And it very rarely ends well for anyone involved.

Realizing success with projects and client relationships (successful customer relationships? Or some other form of customer relationships? Would using another adjective there make more sense? I’m not sure.) requires you take the time to gather requirements by first listening to the customer, understanding the problem(s) they need solved and formulating an effective solution. But it doesn't just stop there. You must also document what worked and didn't work in order to prevent future mistakes. How else are we to learn future prevention if we don't document our current struggles along the way?

That’s why we must always strive for the good version of The 7 Ps: Proper Planning and Practice Prevents Piss Poor Performance. When you take the time to plan out a solution, you will save time, save face AND look like an IT superhero! This is where I like to show some gusto. Planning, testing and verifying, for me, is like getting to play with the toys before buying them. This allows me time to figure out if I like them enough to buy them, that I’m willing to share said toys with friends and that my friends will like them too. Everybody is happy.

But I'm also a realist and know that not all projects we IT Pros are thrown into can be planned and tested 100% of the time. Often we are required to do IT now, best practices be damned, and document it later. Don't forget about budget concerns. It’s an ongoing struggle that we have all found ourselves in more times than we wish to admit. I know I've been there, done that and have the T-shirt. With any positive process though, the change can be difficult to adjust to at first. However, the more we practice positive processes such as planning, testing, and documenting, the  easier they will become with time. We have to first make the change by following the 7 Ps.

To quote The A-Team hero leader Hannibal, “I love it when a plan comes together.” The A-Team practiced the 7 Ps.

photo credit: bon_here via photopin cc