Showing posts with label Policy. Show all posts
Showing posts with label Policy. Show all posts

Monday, 15 December 2014

DataCenter 101 - Documenting DataCenter - Make it Visible

By now we had an Overview of DataCenter; we learnt about Racks, Cables and its labeling too. We will go in-depth about few concepts for Power, Cooling, and HVAC in future along with learning technologies like Blade Enclosures, Virtualization and SAN Storage. But first, since now you might notices what you have in your datacenter, lets capture it first. Documenting your datacenter is the most important phase in your datacenter deployment. It’s important when it comes to Managing your Datacenter

I have seen people capturing Server Implementation Plans (SIP), Network Implementation Plans (NIP) and Standard Operation Procedures (SOP) for New Deployments, but where is the mapping of this information to actual physical deployments. You may an inventory available with you where you have your rack location against your server/storage/switch equipment, but can visualize your datacenter with that? In a way that I give you the information in excel sheet, and you are new to your company and something goes wrong; now I need your assistance to walk-in to the datacenter and check if the cables connections are fine for a particular setup; so you think you can do that with your current available information? Imagine the time you would lose in tracking it even though you have labels in your datacenter. You know time=$$$ right!! So I suggest, invest sometime in making it how you visual it so that you don’t have single point of failure in absence of people who deployed it.

I believe you are convinced by now that why you need to create datacenter documentation. So let’s talk about what need to be captured (suggested) in this document and what you need for that.

To Be Captured:

1.       Overview: It’s like a summary of your datacenter, how it looks. I prefer to mention who designed the document and who owns the document along with who reviewed and approved the document as important information to be mentioned in the beginning itself. It’s give a level of confidence on the document. Like I mentioned, this shows how it looks don’t jumble the position of equipment, racks and their location within. It should be like a photo as it looks.

2.       Power: I believe it’s a good practice to mention the current operating power and max requirement specification based on engineering design. You would need assistance of your local maintenance guyz to measure operating power in peak hours. Suggest you to take max noted in one week or you can take average as well. As per my experience, usually 3 phased power is used in a datacenter. In this example, R-Red, B-Blue and Y-Yellow is named as three phases and its consumption across a rack. You need to notice on the total power available in a circuit and its consumption.

3.       Network LAN: Next comes the Network connections, ISL and bandwidth usage presentation. I would suggest to make one more sheet to represent the IP subnet used in individual racks along with number of ports. This comes handy when doing a root cause analysis in case of network break-down.


4.       Storage SAN: Storage connections are usually tricky and gets messy if your datacenter goes scalable on-demand without proper planning. It is suggested to give a visualization of how storage connections are made across racks and then a logical presentation of ISL connections. Its comes handy when troubleshooting performance issues.


5.       Server Connections: I always to show case a cable connection within a rack and it should be pasted or available as reference material with critical deployments. Imagine you had to remove cable connection for maintenance or replacement of any components and cables get swapped? This is suggested for deployments in a rack.

6.       Setup Configuration: This is a brick level logical presentation of your deployments; where you map how your physical infra (Server, Storage, Network and most important Applications) exist in different layers. I have seen this in Server Implementation Plans (SIP) but not sure if everyone provide the detailed information about the deployments every-time like physical rack information, Management IP etc. Sharing some examples below:



7.       Contact Information (Disaster Run-Book): This section should always come either first or last, preferred last though. This should mention the on-call IT team members name and contact information along with respective areas of expertise like Windows, VMware, Server, Storage, Network or domain of ownership like Power, Cooling, Space etc. This comes handy and becomes a reference in case of Disaster. You can also mention Vendor support information like Contract IDs, Support Numbers, Account Managers Info etc so that you don’t have to search it everytime.

What You Need:

8.  Visio: When it comes to tools, Microsoft Visio is the best one I have seen. You would need stencils to give a real picture of your datacenter. Generic ones should be avoided or should be used only for logical explanations like routing/firewall setups, but what if you need to show actual physical connections? I have seen many usual stencils available on Visio-cafe (ask Google); rest you can ask the vendor for it, they usually provide it as free of cost. Note that there are certain open-source tools available, but they may or may not give the precision to show-case your datacenter. I may be biased, but I am just a fan of Visio.

9.   Information: Apart from tools information is most important. It may be available like a document for setups or like an excel sheet for inventory. Make sure you validate the inventory before you actually deploy it. Most important, you need to make sure this information is kept up to date.

10. Owner, Reviewers & Approvers: To make sure you have the proper information and its mapped as is; Get it reviewed from your peers (Important). See if they have any comment or suggestion or doubts before you actually publish it. What’s the use of it, if they don’t understand it. Like I mentioned before, its less technical document but more logical document. Owners are required to keep information up to date and approvers are required so that this can be use a standard reference documents and can be published.

Special Notes:
There are couple of tools available which easy your work for making automatic diagram via environment discovery like HP SAN Visibility (free), VMware Maps (free) and some other third party tools. However, you would need to consider the pros and cons that comes with these tools like support limitation, cost, credentials or access requirements etc. Adding to it no tool shows you rack placement.

Any more questions? please write back or comment here. There are more things to share.. 


Request you to join my group on Facebook & LinkedIN with name "DataCenterPro" to get regular updates. I am also available on Tweeter as @_anubhavjain. Shortly I am going to launch my own YouTube channel for free training videos on different technologies as well. 

Happy Learning!!


P.S.: I understand the example was given using small deployments, but it may look tedious when it comes to bigger deployments. Yes! It will be, if done by one man army J suggested to divide the work with respective areas of expertise or domain to make it easy, which can be later complied together.

Thursday, 27 November 2014

Best Practices: Data Backup Strategy

While I was working with as Pre-sales Consultant with a Backup Software Company, the most common question I use to come across was "How should I backup my Data?" or "How frequent I should Backup my data?" or "what Strategy I should use to backup my Data?"

Many companies these days define a data backup policies with the retention period or type of backup during a certain period. Many of the backup strategy are defined by users say "Tower of Hanoi" or "Grand-Father-Son (GFS)", along with options like One time Full or Immediate Incremental backup, which are usually manual or with defined schedule.
However, I feel custom options, are for those, who really want to extract & use this software as efficient, as it is, to get complete ROI out of this application. Their are many dependencies or I can say "check list" before defining the a True Backup Plan. Space & Retention period plays the main role while defining the backup plan. While considering these parameters, we should also not forget what your software can do for you, like its Compression rate, around 55%, which I feel is the maximum I have seen as compare to other players in market. Apart from these, we should consider, am I looking for Data availability or Business Continuity. I should also consider RTO (Recovery Time Objectives) for the backup, the more number of backups we will have, the more time it will take to recover, which is standard for any application. These days some Backup Recovery products provide speed of around 1.3GB per minute. 
To clarify more about it, lets think of a scenario, where I have to 200GB of Data to be backed up in 2TB of Space across SAN. Now as per company policy, i have retention period of 6 months.  I am considering data is coming from a single server and we are doing the Image backup, not the files or folder. Now, the moment I will be doing 1 full backup in a month, with 4 differentials in week & daily incremental, I dont think we can achieve our target for keeping backup for 6 months, as usually differential backups are half the size of full backups. This doesn't mean option for GFS is bad, its just its the right choice in every situation. Backups are critical and part of every DataCenter compliance. They should be well defined, tested and implemented, considering the needs of the user. Backup Software is just an application, which can make wonders, but how to make wonders, its up to us. 
Coming back to the scenario, if the user would have selected the Custom Backups, with 1 full backup & daily incremental backup, it would have been enough. It will also provide me Business continuity as I will have less number of backups to be recovered and I can extract any file as well, hence have my data availability as well. 
Please Note Though sometime speed of backup also matter to us, but I am ignoring this fact since currently we are discussing the backup strategy, as speed is already pretty good as observed around 1.3GB per minute. However, we should consider the speed of backup application & connected storage speed of data transfer, when we have multiple backups running simultaneously. During that stage, we have to consider options like bandwidth allocation & de-duplication as well. 
Other Best Practices, I can think of, are as following (Please note, this is Purely on my Experience basis)
1. Do not give the passwords, wrong password attempts may corrupt the backup or can interrupt the backup operation when running a schedule. 
2. If number of machine is above 20, its better to create individual plan for group of machines. You may also consider creating different folder for backup in same location. Anyhow the backup plan waits for completing the previous plan, so like I said, its up to you, how you want your software to work.
3. Tapes are Pre-Historical :) (slow), These days backup application are New Generation (very fast), I dont prefer Tape if duration of backup recovery matters to you. Even though backup speed can reach up to 2GB per minute, but since target speed is low, data backup will be slow as well. However, they are still required but as offsite copy, should not be used as primary. 
4. Dont backup single machine on a de-duplication enabled location, since it will check for data redundancy in same location and will take time to complete backup.
5. Make sure you are using option to validate the "Full Archive" 
6. I always suggest to take backup on two different locations, if possible with no financial constraints to invest for data availability under Disaster Level 5. 
7. I suggest to take full partitions backups rather then filer or folder, since even though backup is of drive, we can still do Files & Folder recovery. Also, its much faster as does backup sector by sector and auto include any new file created in same folder location, which infact does not happen if we do files & folder. 
8. Drill for Test recovery should be done oftenly, atleast once in 3 months. 
9. Bootable CDs should be kept ready with latest version of kernel. Problems usually dont knock door before coming. We should be armed to fight against them. 
10. Notification plays important role. Make sure you are getting notification via email or SNMP. If its SNMP, make sure your Trap catcher is listening alerts. 
Feedback, Questions will be Appreciated. 
Note: This article is re-posted, earlier it was posted on vendor site. Its still a Hot thread in their community. FYI https://forum.acronis.com/forum/17555 

Any more questions? please write back or comment here. There are more things to share.. 

Request you to join my group on Facebook & LinkedIN with name "DataCenterPro" to get regular updates. I am also available on Tweeter as @_anubhavjain. Shortly I am going to launch my own YouTube channel for free training videos on different technologies as well. 

Happy Learning!!