Full and final VMware environment set up--suggestions needed!!!!!

[virtualbot]

Sorry everyone, had some errors attaching the file. I did it twice but it failed. So I pasted it here.

The environment consists of 6 ESX 3.0.5 hosts managed by Virtual center 2.0.5. The ESX hosts are deployed on DELL Power Edge 2950s. Virtual center and license server are placed on a server together.

Proposed VM deployment:

1) SQL 2005 servers

2) 2003 servers

3) XP Machines

FC SAN DETAILS:

Disk details = 22X750GB SATA disks with 7200 RPM

Total raw space = 16.5TB

Total usable space (after 2 hot spare disks, disk over head and RAID5-5 over head) = 10.5TB approx.

LUN CARVING DETAILS ON SAN:

1) 6 VMFSes for each host i.e. VMFS1, VMFS2, VMFS3, VMFS4, VMFS5 and VMFS6

2) VMFS (1to6) capacity = 350GB approx.

3) All these VMFSes are visible to all the hosts, to enable Vmotion, HA and DRS

4) Remaining 8.4TB usable space is carved into 8 LUNs each with 1.05TB

5) SQL databases will be placed on these 8 LUNs. Also all these LUNs are visible to all the hosts

VM details:

1) One VM will be created for each database. A copy of the original database is created and this replicated database will be used by 2 or more concurrent users using the same VM. The golden image of the database is always untouched. All the databases will be accessed by 2 or 3 ESX hosts at the maximum.

2) All the other VMs are either 2003 servers or XP workstations.

ESX BOOTING:

The ESX Hosts will be booting from the SAN.

1) An image of the ESX software will be loaded in one of the LUNs in SAN and only this LUN is presented to the respective ESX host at the time of boot. All the other LUNs will be masked. The other 5 ESX hosts will be booted in the same fashion

REVERTING AND SNAPSHOTTING:

1) When the users work on the replicated database, the changes are saved using the snapshot feature of the SAN. The snapshot scheme is dependent on the frequency in changes (e.g. Incremental, differential etc.)

2) When they want to delete the changes made and revert back to the original database, the snapshots of the replicated database are deleted and the user is reverted back to the replicated database. This reversion is carried out at the storage level using pointer based reversion.

MY QUESTIONS:

1) The initial boot partition at the time of ESX installation should be done on the local disks of the server or on the SAN? (local Disk Space= 750GB approx)

2) If I am doing everything on just the SAN, what about the local disks??

ANY SUGGESTIONS, ADVISES AND QUESTIONS ARE HIGHLY APPRECIATED. ALSO, PLEASE CORRECT ME IF I AM DOING SOMETHING WRONG OR RATHER STUPID!!!!!!!

TIA

virtualbot

Message was edited by: Ken.Cline to remove all caps from subject

[ctfoster]

MY QUESTIONS:

1) The initial boot partition at the time of ESX installation should be done on the local disks of the server or on the SAN? (local Disk Space= 750GB approx)

The boot partitions are on the SAN LUN - otherwise it's not 'Boot from SAN' - it's 'Boot from a local disc which points at a SAN LUN', Thats not the same thing.

2) If I am doing everything on just the SAN, what about the local disks??

Have you considered e-Bay. :smileyblush: But seriously if you are going down the Boot from SAN route a major benefit is gained by treating the 2950 as nothing more than a headless CPU/memory resource. Once you start getting clever with the local drives this approach is somewhat diluted.

[virtualbot]

Thank you ctfoster!!!! what about the rest of the set up?? Does it make sense????

[ejward]

What type of SAN are you using? We had issues with SATA drives in our EMC Clariion. EMC gave usWe have since migrated to iSCSI storage.

[virtualbot]

Probably Compellent (FC/iSCSI SAN). It could even be Dell AX4-5F (FC SAN). Still waiting for the quotes to be approved. My recommendations were Compellent though. Any idea at all about how good AX4-5F is???

[ejward]

We're using Dell / Equallogic but there's a local hospital that uses Compellent with iSCSI and loves them.

[virtualbot]

yeah, I remember you told me that!!!! I found equallogic a bit expensive when it comes to scalability. especially for our test/dev setup. Expansion with Dell AX4-5F or Compellent is more viable...as far as I digged in!!!

[Ken_Cline]

Sorry everyone, had some errors attaching the file. I did it twice but it failed. So I pasted it here.

First, a moderator comment - please do not use all caps in your subject - it is considered bad form.

The environment consists of 6 ESX 3.0.5 hosts managed by Virtual center 2.0.5. The ESX hosts are deployed on DELL Power Edge 2950s. Virtual center and license server are placed on a server together.

No problem, but you will typically get "better" performance out of VC by separating your management server and your database server.

Proposed VM deployment:

1) SQL 2005 servers

2) 2003 servers

3) XP Machines

OK, how many VMs?

FC SAN DETAILS:

Disk details = 22X750GB SATA disks with 7200 RPM

Total raw space = 16.5TB

Total usable space (after 2 hot spare disks, disk over head and RAID5-5 over head) = 10.5TB approx.

This could be great, or it could be terrible. It's all going to depend on the I/O workload you throw at the storage subsystem. With large, slow SATA disks, you get lots of capacity, but not lots of performance.

LUN CARVING DETAILS ON SAN:

1) 6 VMFSes for each host i.e. VMFS1, VMFS2, VMFS3, VMFS4, VMFS5 and VMFS6

I assume you mean "6 VMFSes, one for each host" and not truly "6 VMFSes for each host" which would mean 36 VMFSes.

How are you going to map hosts to VMs to VMFS volumes? You may start out with VM-1 on VMFS-1 on Host-1, but if you're going to use DRS, HA, or simply VMotion things around, your mapping will get mixed up pretty quickly.

2) VMFS (1to6) capacity = 350GB approx.

3) All these VMFSes are visible to all the hosts, to enable Vmotion, HA and DRS

4) Remaining 8.4TB usable space is carved into 8 LUNs each with 1.05TB

OK, although don't count on the capacity coming out to exactly these numbers, there's overhead in them thar storage systems!

5) SQL databases will be placed on these 8 LUNs. Also all these LUNs are visible to all the hosts

These will be RDMs? No problem either way. Just be wary of performance. Again, you've only got 22 spindles spinning, and slowly at that. Count your IOPS and make sure you have enough.

VM details:

1) One VM will be created for each database. A copy of the original database is created and this replicated database will be used by 2 or more concurrent users using the same VM. The golden image of the database is always untouched.

OK. Where will this "golden" DB reside? Is it on the same LUN as the working copy? Do you have additional storage for it somewhere else? Is this database simply reference data that does not get changed? What happens to all of your changes if you need to roll back to your golden copy?

All the databases will be accessed by 2 or 3 ESX hosts at the maximum.

I don't understand this statement. Do you mean the databases will be accessed by client VMs on 2 or 3 ESX hosts?

2) All the other VMs are either 2003 servers or XP workstations.

OK. How do you plan to configure them (RAM / vCPUs / etc.)?

ESX BOOTING:

The ESX Hosts will be booting from the SAN.

Check the HCL to make sure your SAN is supported for BfS

1) An image of the ESX software will be loaded in one of the LUNs in SAN and only this LUN is presented to the respective ESX host at the time of boot. All the other LUNs will be masked. The other 5 ESX hosts will be booted in the same fashion

The boot LUN must be the first visible LUN for the ESX host (lowest number LUN on the lowest number HBA)

REVERTING AND SNAPSHOTTING:

1) When the users work on the replicated database, the changes are saved using the snapshot feature of the SAN. The snapshot scheme is dependent on the frequency in changes (e.g. Incremental, differential etc.)

2) When they want to delete the changes made and revert back to the original database, the snapshots of the replicated database are deleted and the user is reverted back to the replicated database. This reversion is carried out at the storage level using pointer based reversion.

OK. This has nothing to do with ESX

MY QUESTIONS:

1) The initial boot partition at the time of ESX installation should be done on the local disks of the server or on the SAN? (local Disk Space= 750GB approx)

BfS does not use local disks. Either install ESX locally and boot from local or install it on the SAN and boot from SAN

2) If I am doing everything on just the SAN, what about the local disks??

In general, I try to keep the local drives small and use them for booting the ESX environment and not much else. If you're planning to use MSCS, you will need to put the boot drive of your VM on local storage (which means no VMotion/DRS/HA).

ANY SUGGESTIONS, ADVISES AND QUESTIONS ARE HIGHLY APPRECIATED. ALSO, PLEASE CORRECT ME IF I AM DOING SOMETHING WRONG OR RATHER STUPID!!!!!!!

TIA

virtualbot

Ken Cline

Technical Director, Virtualization

Wells Landers

VMware Communities User Moderator

[virtualbot]

Firstly thank you very much ken for your time in responding to my thread. I will make a note about the caps next time. Thank you for mentioning it. I have provided some more details below about the setup based on your questions.

1) OK, how many VMs?

Typically about 60VMs.

2)This could be great, or it could be terrible. It's all going to depend on the I/O workload you throw at the storage subsystem. With large, slow SATA disks, you get lots of capacity, but not lots of performance.

The I/O is going to be very low on these spindles. May be 2 users work on a spindle at a time.

3) I assume you mean "6 VMFSes, one for each host" and not truly "6 VMFSes for each host" which would mean 36 VMFSes.

How are you going to map hosts to VMs to VMFS volumes? You may start

out with VM-1 on VMFS-1 on Host-1, but if you're going to use DRS, HA,

or simply VMotion things around, your mapping will get mixed up pretty

quickly.

Yes, 6 VMFSes in total. One for each host. Initially I am going to do the VM1 on VMFS1 on Host 1. And yes I can definitely see the mix up very soon. As long as the performance is good, I dont really mind the mixup.

4) These will be RDMs? No problem either way. Just be wary of performance. Again, you've only got 22 spindles spinning, and slowly at that. Count your IOPS and make sure you have enough.

After reading many threads and documents, I felt RDMs would be the best solution for the databases. But can you throw some light on RDMs? How to configure them etc.?

5)OK. Where will this "golden" DB reside? Is it on the same LUN as the working copy? Do you have additional storage for it somewhere else? Is this database simply reference data that does not get changed? What happens to all of your changes if you need to roll back to your golden copy?

I am planning to put the golden DB on a separate LUN. It is never changed. I will only roll back to the replica of the golden DB, it is on this replica that the users work and make some changes. I will delete the unnecessary changes (snapshots). This is all a test/dev setup.

6) I don't understand this statement. Do you mean the databases will be accessed by client VMs on 2 or 3 ESX hosts?

Sorry for the way I phrased it previously. A database will be accessed by 2 or 3 users. So can both the users access the database concurrently using the same client VM connected to the database?

7)OK. How do you plan to configure them (RAM / vCPUs / etc.)?

Right now I have no idea. Just planning to give the basic requirements. But will change the settings as required based upon the performance. Do you think its a wise idea??

TIA

virtualbot

[Ken_Cline · Accepted solution]

4) These will be RDMs? No problem either way. Just be wary of performance. Again, you've only got 22 spindles spinning, and slowly at that. Count your IOPS and make sure you have enough.

After reading many threads and documents, I felt RDMs would be the best solution for the databases. But can you throw some light on RDMs? How to configure them etc.?

A good place to start for information on RDMs (and SAN configurations) is the SAN Design and Deployment Guide

6) I don't understand this statement. Do you mean the databases will be accessed by client VMs on 2 or 3 ESX hosts?

Sorry for the way I phrased it previously. A database will be accessed by 2 or 3 users. So can both the users access the database concurrently using the same client VM connected to the database?

Assuming the application running within the VM can support multiple concurrent users, then sure - not a problem.

7)OK. How do you plan to configure them (RAM / vCPUs / etc.)?

Right now I have no idea. Just planning to give the basic requirements. But will change the settings as required based upon the performance. Do you think its a wise idea??

Yes, that's an OK way to go. Basically, I'd suggest starting with your XP VMs having a single vCPU and 512MB (or less) vRAM. Since your DB servers are pretty light weight (or so it sounds), I'd also start them off with a single vCPU, but bump the RAM to 1GB. Wash, Rinse, Adjust Accordingly

Ken Cline

Technical Director, Virtualization

Wells Landers

VMware Communities User Moderator

[virtualbot]

Thank you very much Ken, for your time and advises. Now I am feeling better about the whole setup.

[azn2kew]

RDM has neither physical or virtual options, basically with physical option you will gain better performance but lack of ESX snapshots and other advance virtualization features. You can convert from physical mode to virtual if you want. You have to carve your LUN and have it visual to any of your ESX clusters and than when you create your virtual machine, you add new hard drives and choose "Raw Device Mappings" 3rd options and than point to the LUN you've created.

For resource allocation and management, I would use Resource Pool just to provide better administrative function and also guaranteed the reservations of resources dedicated to production/dev if you have to and set specific rules to them if you want. I would not over allocate any resources to unnecessary systems especially vSMP features, only assign vSMP to systems that maximize and utilize CPU cores otherwise go with standard 1 vCPU and 1GB RAM to start with always change RAM if there is a need for it. My Citrix servers have 3.5GB RAM for themselves and works fine. File/Web servers tend to use 1GB ram doing fine for our purpose but yours might be different. You have to check performance and allocate more anytime.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

[virtualbot]

It was good insight about the RDMs azn2kew. Thank you very much. Even though I knew the theoretical concepts of RDM I was unaware about how to configure. Now I get it from your answer.

And yes, I am definitely going to use Resource pools that way I need not worry a lot about allocating resources every now and then.

Thank you,

virtualbot