cmga
asked on
Best practice for lun presentation/carving for SQL instances
Hi,
We are about to upgrade our current SQL environment which will utilise our current SAN environment. We currently have two SQL instances, one physical and one virtual (ESX).
I have configured three LUN’s on our SAN which are:
- VMFS_LUN (ESX Server storage)
- Data_LUN (SQL data)
- Logs_LUN (SQL logs)
Below are the two SQL server instance and their disk configurations.
SQL Physical Server
C: Local disk - OS + App install
D: Shared storage (Log_LUN)
E: Shared storage (Data_LUN)
SQL Virtual Server
C: Shared Storage (VMFS_LUN) - OS + App install
D: Shared storage (Log_LUN)
E: Shared storage (Data_LUN)
My question is related to best practice for lun presentation/carving for SQL instances.
Is it better to create a different LUN for each SQL instance I have? For example: Log_Lun1 (SQL Physical Server) & Log_Lun2 (SQL Virtual Server)
Also on our SQL virtual environment D and E drives, is it better to create these drives as VMFS which point to the Log and Data LUN’s? or should I used the isci initiator in windows?
Any advice or suggestions will be welcomed!!!!
We are about to upgrade our current SQL environment which will utilise our current SAN environment. We currently have two SQL instances, one physical and one virtual (ESX).
I have configured three LUN’s on our SAN which are:
- VMFS_LUN (ESX Server storage)
- Data_LUN (SQL data)
- Logs_LUN (SQL logs)
Below are the two SQL server instance and their disk configurations.
SQL Physical Server
C: Local disk - OS + App install
D: Shared storage (Log_LUN)
E: Shared storage (Data_LUN)
SQL Virtual Server
C: Shared Storage (VMFS_LUN) - OS + App install
D: Shared storage (Log_LUN)
E: Shared storage (Data_LUN)
My question is related to best practice for lun presentation/carving for SQL instances.
Is it better to create a different LUN for each SQL instance I have? For example: Log_Lun1 (SQL Physical Server) & Log_Lun2 (SQL Virtual Server)
Also on our SQL virtual environment D and E drives, is it better to create these drives as VMFS which point to the Log and Data LUN’s? or should I used the isci initiator in windows?
Any advice or suggestions will be welcomed!!!!
Paul Solovyovsky
What are your IOPS requirements, SAN model, and Backup capability?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
IOPS Requirments? Still looking at this.
SAN Model? HP LeftHand Networks P4500
Backup Capability? Databases are backups by SQL and we do a file level backup of all the *.bak files on a nightly basis.
There are no requirements for a VCB image backup of the virtual SQL server as yet, but we will configure an image back of the virtual sql server which will exclude d & e drives.
SAN Model? HP LeftHand Networks P4500
Backup Capability? Databases are backups by SQL and we do a file level backup of all the *.bak files on a nightly basis.
There are no requirements for a VCB image backup of the virtual SQL server as yet, but we will configure an image back of the virtual sql server which will exclude d & e drives.
Is the Physical / Virtual SQL instance for redundancy or just 2 seperate Instances?
Unless you are trying to use some sort of an Active Passive SQL setup, with a SQL Cluster / File Cluster i don't think you'd be able to point to the same LUN from both servers and do a simultaneous RW.
If for seperate instances, I would suggest having 2 different sets of LUNS for the Data and Logs on each server.
Let ESX take care of the LUN than using iscsi initiator in Windows.
Unless you are trying to use some sort of an Active Passive SQL setup, with a SQL Cluster / File Cluster i don't think you'd be able to point to the same LUN from both servers and do a simultaneous RW.
If for seperate instances, I would suggest having 2 different sets of LUNS for the Data and Logs on each server.
Let ESX take care of the LUN than using iscsi initiator in Windows.
The simple answer is you want a config that's balanced and easy to understand without referring to a spreadsheet each time you allocate LUNs. So here's what I've recommended for some of my customers:
RG/LU Carving:
All LU's are the same size. Larger LU's are created by merging multiple LU's together.
Within any raid group, every LU is assigned to the same controller.
RG0/2/4/6/8 -- Even raid groups (RGs) go have all their LU's assigned to CTL 0
RG1/3/5/7/9 -- Odd RGs have all their LU's assigned to CTL 1
A LU can be any four digit number from 0000 to 4095.
First two digits of the LU number matches the RG number, last two digits represent the "slice" within the RG.
So the LU's within RG6 would look like:
0600, 0601, 0602, 0603, ...
You can also make the first ten LU's in a RG small, the rest big, and separate them by gaps in the slice, i.e.: 0600-0612 = 30GB, 0640-0667 = 120GB, ...
This numbering system allows easy space recovery and reallocation when a server is decomissioned.
RG/LU Carving:
All LU's are the same size. Larger LU's are created by merging multiple LU's together.
Within any raid group, every LU is assigned to the same controller.
RG0/2/4/6/8 -- Even raid groups (RGs) go have all their LU's assigned to CTL 0
RG1/3/5/7/9 -- Odd RGs have all their LU's assigned to CTL 1
A LU can be any four digit number from 0000 to 4095.
First two digits of the LU number matches the RG number, last two digits represent the "slice" within the RG.
So the LU's within RG6 would look like:
0600, 0601, 0602, 0603, ...
You can also make the first ten LU's in a RG small, the rest big, and separate them by gaps in the slice, i.e.: 0600-0612 = 30GB, 0640-0667 = 120GB, ...
This numbering system allows easy space recovery and reallocation when a server is decomissioned.
ASKER
No all items where answered.