The Irish Mitsubishi FTO Owners Club

Topic split - CJ

I'm all for this move forward, but I really cannot get behind this cloud networking VM scenario. I would hate to think that MY stuff is just somewhere in a share. Physical processing hardware is what I'll be sticking too. I can't see it hitting the home user for a long time, but if it ever became mainstream for the facebook/youtube nation to have all their stuff available anywhere I see bad things a happening.

Interesting article on the furute of AMD. http://www.tomshardware.com/news/amd-opteron-phenom,5312.html

This discussion is going off a mad tangent tangent but it would rude not to...

I would agree that Software as a Service / Infrastructure as a Service (SaaS / IaaS - more useless IT acronyms) are not geared towards the home user right now (despite the Amazons and Microsofts of this world pushing the same). At a business level, service providers will tailor their SLAs so to integrate with your compliance framework in terms of security and intellectual property, user agreements are much looser. The case for on-site server and network virtualisation in business can be very easily justified in terms of total cost of ownership and return on investment, its a no-brainer in my experience (I've got 60 servers running on 3 x 4-way boxes at the moment). Sticking your virtual infrastructure up into the 'cloud' is another topic entirely but one thats gaining momentum (primarily in terms of hot-sites/disaster recovery / business continuity).

CJ

From a security standpoint though I find it to be questionable at best. The company I work for deal with a lot of high profile client and we run a lot of intensive software. Having already dealt with VM on a medium scale and seen how bad the performance is given the same theoretical hardware as the opposite physical server, I find that if you're dealing with a large set of data, all of which is secure the max, that then going to a cloud services, ESI company, whatever you want to call them, leaves a lot of room for interruption to service, the need for HUGE bandwidth and slower processing. Now I would imagine that a lot of this is to do with how relatively new VM and virtualisation is as a concept that there is a LOT of room to grow. But having data stored off site, outside of your immediate control? Alarm bells come screaming to me. If you have a single location where hundreds of companies store their data then they're going to be open to CONSTANT attack and constantly will have people plotting and planning to bypass their security.

Cloud computing is certainly an area that has a lot of maturing to do. I expect it will over the next decaded however because it has the potential to offer businesses monolithic gains in capital expenditure.

Dilogoat86 wrote:Having already dealt with VM on a medium scale and seen how bad the performance is given the same theoretical hardware as the opposite physical server..

If a proper detailed capacity planning exercise is undertaken, the risk of performance issues following the P2V process should be minimal. This process is one of the most important factors pre-implementation.

Dilogoat86 wrote:If you have a single location where hundreds of companies store their data then they're going to be open to CONSTANT attack and constantly will have people plotting and planning to bypass their security.

Sure haven't companies been co-locating data in off-site datacentres for years now? I can name a handful of blue chips in and around Dublin who have their entire order management / processing, data repositories, e-commerce and business intelligence systems hosted in nameless datacentres in and around the suburbs. If suitable security polices, procedures and frameworks are in place (i.e. those that mimic a would-be onsite datacentre) then the risk is significantly mitigated. Every internet facing network is open to attack, robust security is key to ensuring business continuity in this instance. I managed a a large offsite migration exercise a few years ago - 75% of the work was done during the planning phase and was heavily influenced by policy.

CJ

Any advice for running SQL in a virtual environment? Windows clustering has been removed due to the redundancy of it in a VM enviroment, but there seems to be a lot of issues with setting a SAN up correctly for the VM\SQL system.

Dilogoat86 wrote:Any advice for running SQL in a virtual environment?

Ah, SQL, you've caused me some pain over the years! Some things that come to mind are:

SAN connectivity - whats the medium - fiber channel perhaps? If so, setup the zoning to allow redundant links to be use load sharing, a 4Gbit backbnne should be sufficient.

What type of disks are used in the SAN? If SATA, throw them in the bin and invest in SAS or equivalent, SATA can't provide the throughput for transactional systems.

How are the arrays setup, what about the RAID level?

You've a separate partition for transaction logging, right? If possible, locate your transaction log VMDK on a seperate SAN, at a bare minimum, point them at a separate array. Database and logs on the same partition will bring the application to a snails pace in no time.

SQL specific - invest in a decent DB defrag tool such as Diskeeper, I've seen real gains by using the same on busy production systems. In a physical world, the boot, swap, data and log partitions should all be located on separate arrays (using RAID 1+0 for example). Mirror the physical disk layout in your virtual environment for optimum performance. Give the server loads of RAM, SQL's a glutton for it

Tip: Don't deploy new VMs at the drop of a hat just because you can do so easily. The sign-off process for a new VM should be the same as if you were purchasing and deploying a physical server. The system needs to be maintained, licensed, backed up and adds to the load - all factors that incur time and cost.

CJ

For the software I use in work we have our own seperate SQL instance. As far as I know it's built on a fibre network (I'm not the dba here, I'm support for the software) and it's RAID 5 afaik. Server has a quad core Opteron with 7.75Gb RAM running on 64bit Server 2003 Enterprise. There's no other systems that run off of this server either so it's just for us. We have a max of 10-15 user a day querying SQL through the software and for the most part it's fine. However we've had our issues in the past. Page file, data, logs all have seperate drives on the SAN. Previously, it was running in a cluster environment within the VM but that caused issues.

Dilogoat86 wrote:Page file, data, logs all have seperate drives on the SAN.

Separate drives on the same the same array? If so, split the partitions out to separate arrays. 10-15 users is pretty small scale, first things first - get the DBA to review database activity, he shouild be able to see where locks and /or bottlenecks are occurring. In my experience, 80% of SQL problems relate to schema and design, the rest is infrastructure. Sounds like the DBA should be working closely with the server guys on this one, get the whip out!

CJ

The issue is more so that the software we use is based around an infrastructure design from the late 80s early 90s. Permissions are stored in ini files on the share and they are synched to SQL. The problem is that every time a user connects, the permissions are pulled through SQL from the file share, rather than a simple approach like accounts created in software. It uses the active directory which is fine, but then the permissions are dished out using a schema and hidden database roles. It's very complex and outdated at the same time. For example, they're still stuck in a 32 bit environment and doesn't support .NET > 2.0. They're revising but their competitors are already streets ahead. I don't know if you're familiar with the IDOL engine from Autonomy, but that's an environment that makes database management in todays world look like paint vs photoshop.

With regard to the SQL issues, I blame it more on the softwares use of it, and I think you can agree that the amount of users doesn't really push for a massive SQL setup.

Interesting blog post on more secure cloud computing.

http://chucksblog.emc.com/chucks_blog/2010/03/cloud-security-takes-a-big-leap-forward.html