Friday, 11 March 2011

How to Virtualise your Server Infrastructure - The Learning Curve and Overview - A Brief Introduction

Before we begin, let me just state for the record that all views and thoughts are my own. I have purposfully kept the technicalities of this at a minimum as I dont want to exclude any non technical people per se. So to the very technical people, take the below as it is intended. A brief introduction to the virtualisation world which just barely scrapes the surface of what is going on.

Its been a while since I updated my blog, but that doesn't mean that I haven't been doing nice techie things during that period. In fact for the last few months, I've had my head stuck firmly in visualisation land . We decided to move to a new virtualised server infrastructure last year which also coincided with a huge group level domain migration at the same time. Having played a bit in the virtual server field, I was no expert in the matters so had to look about and see what was most suitable for our infrastructure.


1) The Weapon of Choice
As some of you know, there are a few big names playing in the Virtual Host space in the IT industry. VMWare, HyperV, XenServer to name the top 3. You can go out and read countless arguments for and against all of the above and I wont bore you with technicalities on these. In general terms they all perform as they should and are good at what they do. Google is your friend if you want to know more. To cut a long story short, we went with HyperV in the end. My reasons were simple. Cost! We are predominantly a Microsoft house and running Windows 2008R2 Datacenter on my VM Hosts (those are the physical machines that run the virtual Servers) allows for an unlimited amount of virtual Windows Server Guests to be run in licensing terms. ( I don't have to buy a new 2008 license every time I want to build a virtual Windows Server guest OS)

Terms breakdown:
Virtual Host - The Physical Machine which runs all the virtual machines
Virtual Guest - The Operating System that runs IN the virtual host. You can run multiple Guest OS' in virtual hosts depending on how powerful the virtual host is ( CPU's, Memory, Storage all play a part in this)



2) The Tin - It ain't a Dell, HP or IBM
Tin is techie slang for the hardware running the virtual hosts. This is quite an important step as you don't want to under spec but also if budget is a concern you'll want bang for buck and performance as well. As the company I work for has quite a large virtualisation portfolio, I decided to back them and choose some of the Hardware we sell. The machines are made by VMCo ( Virtual Machine Company) and the specs are as follows.
Specs: 4 x AMD Quad Core Operton Processors (16 Cores)
128GB Ram
32 GB SSD Drive
4 x Dual Gigabit Ethernet Cards
2 x On board Gigabit Ehternet Ports ( 10 in total)
We set up 3 of these for resiliency and clustering of the virtual hosts.



3) The Storage Option - Where to put all this data??
In the virtualisation industry, storage is king!! With EMC and Netapp constantly locked in a struggle for the top spot in the SAN world, the choice we faced wasn't too hard. It was going to be one of those two as our main storage choice. We specced 2 options from each and narrowed the choice down to an EMC NX4 in the end. We backed this up with a small but very efficient D-Link DSN - 2100 SAN as well for backup/testing storage.

Terms Breakdown: SAN = Storage Area Network ( A collection of disks which can be created in a variety of setups for size, resiliency and performance) These disks can then be presented to your virtual environment to be used in any way you need them.

Facts: Total Storage Count : 28 TB/Terabytes = 28000 GB/Gigabytes = 28000000 MB/Megabytes = LOTS OF DISK SPACE !!! And we are considered entry level in terms of storage.



4) Its good to talk - The Networking Option
We had 2 routes to go down in terms of how the SAN's would connect to the Servers. iSCSI or FC (Fiber Channel. iSCSI seemed to be the easier of the two as we were already comfortable with IP networking and this seemed to fit our needs best without huge spend on Fibre Channel Cards and Switches. Juniper EX Switches were installed to cope with the demands of the SAN to Server connectivity.

Terms Breakdown: iSCSI = Internet Small Computer System Interface. This allows for SCSI commands to be carried over IP networks.
FC = Fibre Channel. This allows for SCSI commands to be carried over Fibre Channel networks.


5) Into the Melting Pot it goes - Close your eyes and hope for the best.

I jest of course. Once you have all the components, you spend the next few months of your life, reading, learning, building, breaking, running performance tests, breaking again, running more tests .. you get the idea. Planning is key here and the more time spent understanding what you have put in place the better your virtualised server environment will be :)


If you don't want to go through all that effort, then there is always the "Cloud" infrastructure option, but we'll save those thoughts for another blog on another day!!

Friday, 30 July 2010

when cfparam wont cut it

Random a couple of weeks ago , that in all honesty I should have known


I use cfparam alot, its easy to use and does the Job, but as I have gotten older default values for variables have gotten a little bit more complex than yes/no/now().


So....... at one point I started to do stuff like this (not exactly like this or I would need a better job.)


<!--- set a var--->

<cfset myname =" 'Ted'">


<!--- set a default --->

<cfparam name="myName" default="#_SayMyName()#">


<!--- putput the var --->

<cfoutput>#myName#</cfoutput>


<!--- Function to set default--->

<cffunction name="_SayMyName" returntype="string" output="yes">

<cfreturn>

</cffunction>


Which looks fine and dandy. but then on the execution plan I started to notice that the Function (that held a database lookup in the RL example) the function always executed.


The reason for this, is simple #_SayMyName()# runs the function, there I have said it.


But the golden child that was cfparam now isn't the all problem solving tag as I had previously thought.


So to cut a long story short... the correct answer is thus.


<cfif>

<cfset myname =" _SayMyName()">

</cfif>


*Head bangs off desk*

Functions within cfquery/cfstoredproc loss of datasource

When is the data-source of your query not the data-source of the query ?


So I have a query block that call a table, and within the block I have a function that gets a value I need in the query.


<cfquery datasource="DB1">

Select *

from myTableInDB1

Where id = <cfqueryparam value="#val(_getID())#" cfsqltype="cf_sql_numeric">

</cfqueryparam>


<cffunction name="_getID" returntype="numeric" output="yes">

<cfset q=" ''">

<cfquery datasource="DB2" name="q">

Select top 1 id from AnotherTable

</cfquery>

<cfreturn>

</cfreturn>


So I want everything from myTableInDB1 that is in the DB1 data-source. and I want to pull back everything that has an ID equal to the response from a function.


Sadly that function contains another query which gets an ID from AnotherTable from Another datasource (DB2).


So what happens is I get an error that says myTableInDB1 does not exit in data source, which leads to lots of toy being chucked all over the place. and a moment remenisant of installing a printer in windows 98 "WHAT DO YOU MEAN IT RIGHT @#+-ing THERE!!!"


But what realy happens its the datasource in _getID() is used for both queries.


This issue was compounded that the _getID() set an application variable the first time it was executed, so on subsequent calls to the page the First query would run fine, but err every time I reset CF.


To solve this:


<cfset thisid=" val(_getID())">

<cfquery datasource="DB1">

Select *

from myTableInDB1

Where id = <cfqueryparam value="#thisID #" cfsqltype="cf_sql_numeric">

</cfqueryparam>


Another Head vs Desk moment.


NOTE: This works/doesn't works for both cfquery and cfstoredproc</cfquery></cfset></cfset></cffunction></cfquery>