cancel
Showing results for 
Search instead for 
Did you mean: 

Shared MS SQL DB in VMware?

Former Member
0 Kudos

We are trying to put the following systems into one VMware server:

- Solution Manager (SMD)

- ECC 6.0 Development System (ECD)

- ECC 6.0 QA System (ECQ)

Ideally, we would like to partition our VMware server like this:

- Partition 1 - DB - Windows 2008 R2 Server + MS SQL - 2 CPU cores - 20 GB memory

- Partition 2 - APP - Windows 2008 R2 Server + SMD - 1 CPU core - 4 GB memory

- Partition 3 - APP - Windows 2008 R2 Server + ECD - 2 CPU cores - 4 GB memory

- Partition 4 - APP - Windows 2008 R2 Server + ECQ - 3 CPU cores - 4 GB memory

Basically, we want to share the database. The user count will initially be limited to 1, but might increase to 5 next year.

Hardware is Dual Xeon E5520 with 32GB RAM.

Is this setup possible? What is the typical way to set this up? What can be combined and what can't? Can we optimize it further? Maybe just one CPU core for the db?

I already looked through some of the existing documentation, but I couldn't find any good answers so far.

I also order the German book about virtualization from SAP.

Any feedback would be appreciated.

Thanks,

Jens

Accepted Solutions (1)

Accepted Solutions (1)

markus_doehr2
Active Contributor
0 Kudos

> Ideally, we would like to partition our VMware server like this:

>

> - Partition 1 - DB - Windows 2008 R2 Server + MS SQL - 2 CPU cores - 20 GB memory

> - Partition 2 - APP - Windows 2008 R2 Server + SMD - 1 CPU core - 4 GB memory

> - Partition 3 - APP - Windows 2008 R2 Server + ECD - 2 CPU cores - 4 GB memory

> - Partition 4 - APP - Windows 2008 R2 Server + ECQ - 3 CPU cores - 4 GB memory

Be aware that Windows 2008 R2 is not yet supported, the installation will mots likely fail with that OS version. See http://www.sdn.sap.com/irj/sdn/windows?rid=/webcontent/uuid/901004e6-15ce-2c10-afa4-ec948139a17c [original link is broken]

> Basically, we want to share the database. The user count will initially be limited to 1, but might increase to 5 next year.

So you mean you want to use MCOD?

> Is this setup possible? What is the typical way to set this up? What can be combined and what can't? Can we optimize it further? Maybe just one CPU core for the db?

I'd not install any server with less than 2 CPUs. Apart fromt that the setup looks good.

Markus

Former Member
0 Kudos

If I counted right, you want to assign all 32 GB of RAM to the VMs. Be aware that we recommend to reserve 100 % of the virtual machine's assigned RAM. If you would do so in your scenario, there would be no memory left for the ESX itself.

In you setup, I estimate that you can use 28 - 29 GB of RAM for virtual machines. The rest is used by the ESX hypervisor and the console os. See SAP Note 1056052 and attached links.

Furthermore, overcommitting CPUs is no problem, especially for the processor type you're going to use. So you could assign at least 2 vCPUs to every machine. If the machine does not use its vCPU, it can be used by the other virtual machines.

Matthias

Former Member
0 Kudos

Markus,

Thank you for your reply.

Be aware that Windows 2008 R2 is not yet supported, the installation will mots likely fail with that OS version. See http://www.sdn.sap.com/irj/sdn/windows?rid=/webcontent/uuid/901004e6-15ce-2c10-afa4-ec948139a17c [original link is broken]

Thank you for pointing this out to us. That is really a bummer. It seems that SAP will release the new kernel in Q2 which will be too late for us.

However we found that we can buy Windows 2008 R2 and install Windows 2008 instead (Microsoft Server downgrading rights). This would allow us to upgrade later on.

So you mean you want to use MCOD?

Yes.

I'd not install any server with less than 2 CPUs. Apart fromt that the setup looks good.

You misunderstood. I was talking about reducing the cores for the db. We will definitely go with 2 Xeon E5520.

I read some notes that seem to indicate that cores are only needed for more users. Therefore I was wondering if it would make sense to give more power to the APP servers instead.

Thanks,

Jens

Former Member
0 Kudos

Matthias,

Thank you for your reply.

If I counted right, you want to assign all 32 GB of RAM to the VMs. Be aware that we recommend to reserve 100 % of the virtual machine's assigned RAM. If you would do so in your scenario, there would be no memory left for the ESX itself.

In you setup, I estimate that you can use 28 - 29 GB of RAM for virtual machines. The rest is used by the ESX hypervisor and the console os. See SAP Note 1056052 and attached links.

Yes, I do understand that. I just used the entire memory to simplify my planning scenario. We are planning to use ESXi 4.0 with vSphere and so it is my understanding that the footprint of the hypervisor is very small.

Furthermore, overcommitting CPUs is no problem, especially for the processor type you're going to use. So you could assign at least 2 vCPUs to every machine. If the machine does not use its vCPU, it can be used by the other virtual machines.

This is exactly the feedback I was looking for. We are new to VMware and so we need to understand what can be done to optimize the setup. For that reason I also ordered the only available virtualization book from SAP from Germany.

So, if I understand you correctly you are saying that it is possible to overcommit on CPUs. This is good news. Is there a guidance on how much overcommiting is wise to do? How does this work technically? Will it simply split the core into two if we assign two cores per physical core?

Thanks,

Jens

Former Member
0 Kudos

Hello Jens,

in general, ESX and ESXi do only differ in the console OS. So for other aspects you can treat them as one.

The workload every vCPU has to process is scheduled among the available pCPUs in the server. So, there is no core splitting or similar. To understand the details of CPU scheduling in ESX, you can read:

[VMware vSphere 4: The CPU Scheduler in VMware ESX 4|http://www.vmware.com/resources/techresources/10059]

But to understand the basics of how resources should be configured in ESX, I recommend to start with:

[Resource Management Guide|http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_resource_mgmt.pdf]

SAP and VMware have a strong technical alliance. We care about recommendations (like certain SAP Notes) and some other publications on how to run an SAP system best on VMware. The most valuable document for you might be:

[SAP Solutions on VMware vSphere 4 - Best Practice Guidelines|http://www.vmware.com/resources/techresources/10086]

Kind regards,

Matthias Schlarb

Former Member
0 Kudos

Thanks Matthias.

I actually read through the material you listed before I posted, but I was hoping to get some clarification on the db sharing aspect. Meanwhile, I also received the German SAP Press book about Virtualization and it answered some other questions I had. In fact I find the book very valuable to get started with virtualization in SAP.

I also digged into MCOD some more and the more I read about it, the more I don't like it. In general I am getting the impression that MCOD is no longer recommended because of problems/risks during upgrades. Is that correct?

What about the future? Will MCOD still be supported in ECC 7.0?

If not, it seems that we would be better off revising our landscape to use one db per system. What do other customers do?

This landscape change raises another question. So far we were planning to keep the db, application and logs on different physical storage devices (two RAID arrays and a single disks for the logs) as recommended in some of the OSS notes. However, this will be tough (and somewhat overkill) for multiple systems on a 2U server.

Is there any recommendation on the storage system beyond my findings above? What can be combined? What should be separated?

I guess what I am really looking for is a sample ECC VMware landscape. I mean I am very familiar with the standard SAP system landscape, but I haven't been able to find any optimized virtual landscape examples.

Best regards,

Jens

jens_straten2
Explorer
0 Kudos

After reviewing all the negative comments about MCOD, we decided not to go with it.

In a nutshell we found that the only advantage is saving cost on the shared DB. However, this comes at a high cost of performance, upgrade and maintenance problems. We also noticed that all existing documentation from SAP about MCOD is dated and looking at the latest news it is not clear if MCOD is still a recommended solution going forward.

Therefore we revised our landscape in the following way:

- VMware ESXi - 1 vCPU - 4 GB memory - 250GB? HD (RAID 5 #1)

- ISO Storage for installation DVDs - 250GB (RAID 5 #1)

- SAP LOG files for Partition 1-3 - 1TB (NON-RAID DISK)

- Partition 1 - DB/CI - Windows 2008 R2 Server + MS SQL 2008 + SMD - 2 vCPU - 4 GB memory - 1TB HD (RAID 5 #1)

- Partition 2 - DB/CI - Windows 2008 R2 Server + MS SQL 2008 + ECD - 4 vCPU - 12 GB memory - 2TB HD (RAID 5 #1)

- Partition 3 - DB/CI - Windows 2008 R2 Server + MS SQL 2008 + ECQ - 4 vCPU - 12 GB memory - 2TB HD (RAID 5 #2)

with

Hardware:

2 Physical CPU = 2 Xeon E5520 => 8 cores => 8 vCPUs

32 GB Memory (can be upgraded to 142 GB as needed)

RAID 5 #1 - 3 * 2 TB

RAID 5 #2 - 3 * 2 TB

NON-RAID - 1 * 1 TB

Systems:

SMD = Solution Manager

ECD = ECC 6.0

ECQ = ECC 6.0 IDES

Obviously, it would be better to have a separate RAID array for Partition 1 and 2, but we won't need the extra performance in our environment which will be used for development, certification and demonstration purposes.

As you can see we are doing some overcommitment on vCPUs, but we actually stay below the maximum recommended 200% of overcommitment.

Please let me know if you see further areas of optimization.

Thanks,

Jens

markus_doehr2
Active Contributor
0 Kudos

> - Partition 1 - DB/CI - Windows 2008 R2 Server + MS SQL 2008 + SMD - 2 vCPU - 4 GB memory - 1TB HD (RAID 5 #1)

> - Partition 2 - DB/CI - Windows 2008 R2 Server + MS SQL 2008 + ECD - 4 vCPU - 12 GB memory - 2TB HD (RAID 5 #1)

> - Partition 3 - DB/CI - Windows 2008 R2 Server + MS SQL 2008 + ECQ - 4 vCPU - 12 GB memory - 2TB HD (RAID 5 #2)

What comes to my mind:

  • Be aware that Windows 200 R2 is not yet supported, this will take some more months until SAP releases it (see Note 1383873 - Windows Server 2008 R2 Support). Technically it's possible to install it if you exchange the kernel before the database load starts but tools may give warnings/errors.

  • Install SQL 2008 using sql4sap.vbs, then SP1 and then the latest cummulative update (CU7) so you get build 2766 before you start sapinst. This will enable you to use the most bug free database binaries.

  • set "BCP_LOB=1" in the system environment and use "-loadprocedure fast" as advanced option for R3load to load the database content (much faster) - see Note 1156361 - R3load: Fastload doesn't support LOB-columns

  • You can also optimize the needed space if you use page compression during database load time. This will save at least 45 % of needed HD space, depending on what data is stored even more. To do that you'll need to modify the DDLMSS.TPL file since the installation media does not contain an adapted file (if interested get back). You will have less data to backup and faster I/O throughput (since fewer data must be read) - for the cost of some more CPU.

Markus

jens_straten2
Explorer
0 Kudos

Thanks Markus!

These are great optimization suggestions.

Yes, we were planning to use Windows 2008. My fault. We bought 2008 R2, but MS allows downgrading to 2008. I just forgot to update it in my documentation.

I will post back when the system is up and running. Maybe others will be able to benefit from our experience.

Best regards,

Jens

Answers (0)