Какой raid для vmware
I have just ordered a new rig for my business. We do a lot of software development for Microsoft SharePoint and need the rig to run several virtual machines for development and test purposes. We will be using the free VMware ESXi for virtualization. For a start, we plan to build and start the following VMs - all with Windows Server 2008 R2 x64:
- Active Directory server
- MS SQL Server 2008 R2
- Automated Build Server
- SharePoint 2010 Server for hosting our public Web site and our internal Intranet for a few people. The load on this server is going to be quite insignificant.
- 2xSharePoint 2007 development server
- 2xSharePoint 2010 development server
Beyond that we will need to build several SharePoint farms for testing purposes. These VMs will only be started when needed. The specs of the new rig is:
- Dell R610 rack server
- 2xIntel XEON E5620
- 48GB RAM
- 6x146GB SAS 10k drives
- Dell H700 RAID controller
We believe the new server is going to make our VMs perform a lot better than our existing setup (2xIntel XEON, 16GB RAM, 2x500 GB SATA in RAID 1). But we are not sure about the RAID level for the new rig.
Should we go for having the the 6x146GB SAS drives in a RAID 10 configuration or a RAID 5 configuration? RAID 10 seems to offer better write performance and lower risk of a RAID failure. But it comes at a cost of less drive space. Do we need RAID 10 or would RAID 5 also be a good choice for us?
I use RAID5 almost everywhere, except VM hosts (and a few very heavy DBs). they're way too slow on random writes. RAID1 or 10 is the only way
4 Answers 4
I'd definitely go with three RAID 1 volumes; the usable space is the same (50% of total disks size), but you can choose to place VMs on different arrays,and when two VMs are each one on its own physical disk(s) they perform a lot faster than when they're spread across one big array only.
I'd then place the VMs like this:
First array: OS, IIS, tomcat Second array: MOSS front-end, CRM Third array: MOSS back-end
Depending on your workload, you can place them differently; but having a fully dedicated array for the most disk-intensive VM will surely provide a benefit.
I decided to go with the 3 RAID1 arrays. Though I will lose the performance gains from RAID10 I think I will be better protected against IO bottlenecking seperating the load. Thanks for everyones input.
I would go with the four drives in RAID10 rather than two RAID1 arrays as you will see a performance boost for the SQL VM.
As you have plenty of RAM you can give enough to the other VMs that they'll never need to swap, and I'm guessing they won't need much other disk IO either so won't impact the SQL VM in that way. If they do impose a noticable IO load, put then on the other smaller RAID1 array and let the SQL VM have the RAID10 array to itself.
If you had two or more VMs that imposed a high IO load then you might want to go with multiple RAID1 arrays instead of a RAID10 one, as you could separate their IO load on to different disk sets, but you'd have to do some benchmarking yourself with the app(s) in question to see whether this gives you any noticeable speed benefit over RAID10 (I'm guessing any difference would be small, but it would depend on the loading patterns, and having the larger RAID10 volume would probably be more convenient in the long run then two smaller ones).
3 Answers 3
There's lots of similar questions/arguments on this site regarding R10 vs. R5/R6 but they boil down to "exposure during rebuild". The argument for R10 over R5 is strongest when dealing with the larger, slower disks some buy because their GB/$£€ is better (i.e. 2/3TB 7.2k SATAs) as arrays of these disks can take literally days to rebuild following a disk replacement or addition - meaning the entire array would be lost if a second disk failed during this rebuild window.
For many on this site this risk is too high, myself included. R6 changes this a little but usually brings with it often much slower write performance. Also doing any of this in software further reduces performance during rebuild as all data is going over the same bus, including 'in life' traffic.
You've done a good job of picking your components already and you'll certainly see a huge improvement in performance. If I were you I wouldn't 'fall at the final hurdle' - I'd use R10 knowing you'd done the right thing. If you're concerned about space you can use Thin-Provisioned disks and/or buy the 600GB 10k disks instead of the 146GB 15k disks, the performance drop-off won't be too bad but you'll have a lot more space - you could always buy 4 x 600 today and add 2 more later if you needed the extra spindles?
Actually this is not true. Especially write heavy operations are - bad with a Raid 5. I run Raid 10 for all high performacne servers, and hyper-v is one of them. Espeiclally when patch time comes you can really see how thigns go. That said, the SAS discs were wasted - Velociraptors are nearly as good for a lower price (so that one can put them into Raid 110).
TomTom, what "actually isn't true"? You don't make it clear, I'm recommending R10 over R5/R6, just saying R6 is the worst one for write perf. And you may think SAS is wasted but velociraptors would kill some of my systems, though they are good value.
If this is a mission critical system, then you need to make sure that you've got some spare drives locally should one fail (unless you have some support contract on the hardware that says you can get replacements same-day, but even then a local spare is worth having).
Ignoring that (or assuming the six drives doesn't count spares you might have easy access to) I would suggest RAID10 (three RAID1s nested in a RAID0) over RAID5 for the performance reasons you mention. Or if space is not at all an issue and redundancy and rebuild-on-drive-failure time is a big concern, then you might even consider two three-drive RAID1s nested in RAID0 (but that is overkill for most purposes, though it would allow two drives on each R1 leg to fail at the same time while keeping the array alive).
There is another option though: three separate RAID1 arrays (or possibly two RAID10 arrays if your controller supports 3-drive RAID10 (RAID1E as some controllers call it)). This way you can spread the VMs over different spindles so they will compete with each other far less for IO bandwidth. Two VMs on different RAID1 arrays can be merrily thrashing their virtual disks without much affecting the responsiveness of each other or a VM on the third array. Of course this can end up being wasteful space-wise: you may end up with a lot of free space on one array but don't want to use it as there are already I/O intensive VMs in constant use on that array for instance (though in this case if you had a single array the VM you would put in that space would be competing for IO access like that anyway), or you may end up with 25Gb free on each array but need 50Gb for a new VM.
This technique can make a lot of difference with spinning-disk-and-arm based drives if you balance your VMs between the drives right. It still makes a difference on SSDs too, but less so as you do not have the head movement and waiting-for-the-right-sector-to-pass-by issues causing extra performance killing latency. Though as I said above, it can be more work to manage. In the use case you describe, you might put that lightly loaded sharepoint server and the build-master on one array and the development VMs on another (possible one array each, if you have three arrays and no other active VMs). As needs change you can always move the VMs around the arrays to rebalance the load with little down-time (no down-time at all if your chosen virtualisation solution supports live migrations between local data stores).
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- VMware Technology Network
- :
- Cloud & SDDC
- :
- vSphere Upgrade & Install
- :
- vSphere Upgrade & Install Discussions
- :
- What is the recommended RAID configuration for a S.
pbalderos
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I am planning to deploy a single ESXi host to one of our remote sites that will hold no more than 5-8 VMs. I am wondering what others are using in terms of RAID configurations and SAS drives?
Also, I thinking of going with a server model like the Dell R710 that comes with two SSDs that I can mirror and install the ESXi Hypervisor on it. I have never used and SSD to hold the hyper, has anyone and what do you think?
pubudu326
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
whatever disk (SSD or HDD) you used you need minimum raid level. In here you have two disk so you can configure raid 0 or 1. When created RAID 0 you have full capacity as usable both disks. But in RAID 1 it will reduce usable capacity rather than RAID 0. Best practice is RAID 1 and create small amount LUN for Esxi partition.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Data RAID depends on what you can afford and what you are looking for in terms of performance. Usually people go with a simple RAID-5 set if they have a limited number of VMs. For the Hypervisor (ESXi) there's no point in going with 2 SSDs in RAID. ESXi loads in to memory, as such the performance the SSDs provide you normally will not add much, only during boot and you don't do this regularly. So go for DUAL SD Cards, which is a lot cheaper and still provide resilience.
iamamit
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
You should consider having two RAIDs technically, RAID1 is for OS(ESXi Host) and RAID5 with/without Hot Spare drive for Data LUNs of VMs as you are going to have OS as well as data on the same server. This is the best practice most of Engineers follows when they have single server to run OS as well as Data computes.
This helps in having great performance and better protection of your data.
If you have feasibility to combine SAS+SSDs for the RAID5 volume, that should be great as it may help you having maximum performance for read/write operations performed by VMs. my thought, In such single server environment OS is not required to have SSDs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I can't offer a rule of thumb, but some thought you may consider for the design (some of them were already mentioned before):
- space requirements
- performance requirement (note that for performance you also need a controller with a BBU option)
- number of HDDs, and HDD sizes
Why HDD sizes matter? RAID1, and RAID5 can handle a single HDD failure, and needs a rebuild on a new HDD in order to be save again. For large HDDs (>1TB - my personal limit) a rebuild can take considerable time, and puts high load on the disks, so I'd rather consider RAID6 fo such disks. In all cases plan for a Hot-Spare disk.
pbalderos
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Thanks for the feedback!
I will not be going with SSD. Just looking at something like 2SD cards mirrored for the esxi hypervisor and 4 sas (3 for RAID 3 and one for hot spare).
pbalderos
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Thanks for the feedback a.p.
This is what I was thinking
2SD cards at RAID1
Three, 1TB sas drives (15k? perhaps)
I do like your suggestions about using RAID 6 (4 disks) + 1 hostspare. That would give me a 2 disk FT, and from what you are saying the rebuild time would not be an issue
Gavis4569
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I doubt that 2 SD cards can be used to create Raid1 mirror. Even if you will be able to do that ESXi will probably dont recognize such raid and you will see two single SD cards avaliable for installation.
You are not goiung to use VSAN (which requires really free disk) so why to use SD card? Just create desired RAID on the top of your disks and install ESXi on that logial volume (volume will be partitioned and you will loos few GBs from the total capacity but the rest will be used as a datastore).
As aleredy mentiond desired RAID level depends on required capacity and performance you are looking for. If you have few spare bucks I would look at Intel 3610 SSDs.
jhague
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Depends on the server but certainly something Dell
and Cisco offer and arguably cleaner/cheaper than having
hyvokar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Modern servers (at least dell, hp, lenovo) has dual sd modules, which can use raid1 for 2 sd cards.
They are usually presented to the hypervisor as a usb-disk, so esxi installer has no problems detecting them.
Anyway, I agree, that if you are not going to use diskless server, there's no point getting the sd cards.
hyvokar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
On a 5 disk server raid6 + spare is a bit of an overkill.
If you are planning to use 5 disks, I'd recommend raid5+spare (disk space) or raid10 + spare (for speed). Raid6+spare would be the most wastefull option imo, regarding both speed and disk space.
Stanley_
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
for sure OS (ESXi) install on 2x SD cards.
The rest depends on VM needs. we usually using RAID10 (4x or 8x - 1.2TB SAS disks). if you dont need performance use RAID6.
tested on hundreds of single ESXi hosts around the world
continuum
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Single ESXi hosts with local VMFS-storage using RAID5 seem to be that type of environment that run the highest risk of dataloss due to VMFS-cirruption problems.
Thats the lesson I learned in a few years of remote recovery work.
So I tell all my customers to avoid Raid5 at all costs.
Another design mistake I see a lot in small environments is the use of a single datastore only.
This produces big problems when that VMFS-volume needs maintenance.
So my recommendation for single hosts with local storage is to use datastores not larger than 2TB (anything much larger than that can no longer be evacuated during a night or weekend).
Another important tip to survive unexpected power failures without problems is to use eager zeroed thick provisioned vmdks for all VMs.
The more thin provisioning is used (thin vmdks and snapshots) the higher the risk to lose data during power failures.
________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time .
MDNaseer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Raid 1 for Esxi os and Raid5 for data store.
MCX_CZE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
O.k. I have seen a lot of weird configs, like you guys have 4 HDDs and you somehow combine them with 1 hotspare and 2x in RAID 0 and 1x in RAID 1, I am blabling right now. But its weird ? ..
Why not go the easiest way, Buy some 3rd party Raid Controller, IE Adaptec, Put 4 HDDs in it, and make it a RAID 5, you can hot swap them, Raid 5 has redundancy, unlike RAID 0, and you get boost in reading speeds, but unlike RAID 1, You will write slowly, but depends on what are you going to use that, Nowadays RAID Controllers has a 1 or 2 GB Cache, so a lot of stuff is usually handled pretty well and it manages the disk itself.
Never-ever-ever-ever in your life go with original MB Raids.. .Since they usually cut some money on that and you get really weird RAID setups.
RAID 5, with ability to Hot-Plug HDDs even in SATA, (3rd Party controllers can do that).
Youll be thanking me later when of those HDDs go woink.
Why I replied ? I was originaly searching which RAID adapter to use, that could implement itself into ESXi dashboard, so it will show me the HDD status. Well going to look elsewhere, See ya o/ And Happy uptime.
EDIT: Why are you guys putting ESXi OS in SSDs, SD cards etc. ? I would be cold-sweated every day, when that goes away Ill lose my config. So I"ve installed ESXi right on my RAID 5 HDD's, Its a logical volume, so what we should be doing is to create and maintain 1 logical volume, that should be alive, no matter what, Not create more of Logical Volumes. O.k. Boot time maybe quicker but still ?
В наш век облачных сервисов, AWS Lambda и прочих шаред хостингов абсолютно неосязаемых вычислительных ресурсов иногда хочется немножко своего. Кроме желания, иногда бывают и потребности вдумчиво покрутить тот или иной программный продукт с минимальными затратами на платформу. Найти какие-то излишки матчасти можно почти всегда, иногда даже получается собрать всё вместе и включить. Если излишки эти представляют собой CPU хотя бы на 4-6 ядер и памяти от 64ГБ — вообще отлично, можно брать ESXi и работать с чем угодно. Одна проблема: с дисковой ёмкостью на бытовом железе у VMWare — совсем никак. Производительность локальных одиночных HDD невысокая, а уж утратить содержимое отдельно взятого, сферического в вакууме винта в 21м веке — это как здрасьте. Попробуем подключить что-нибудь по сети.
TL;DR> объединение, балансировка, rr limit, вот это вот всё.
Собственно, текст далее не про то, что это вообще возможно или ноу-хау какое-то. Интернет полон статьями для чайников (вот здесь ставим галочки, затем Next, Next, Done) о том, как подать дисковую ёмкость по iSCSI. Пишу как раз для того, чтобы исключить «ошибки выживших» и поделиться моментами, когда «всё пойдёт не так» (а оно пойдёт, Мерфи был прав), и при попытке нагрузить решение оно просто падает.
Итак, мы попробуем раздушить наш «бытовой гипервизор» внешним дисковым массивом, подключенным по сети. Поскольку у нас всё крутится вокруг «недорого», пусть это будет FreeNAS и 4 SATA-диска, которые обслуживает средненький 3 ГГц 45-нм проц. Смотрим на Ebay, и за сравнимые с б/у RAID-контроллером деньги тащим оттуда пару сетевых карточек i350-T4. Это четырёхпортовые гигабитные адаптеры от Intel. По ним и будем связывать хранилку с гипервизором.
Немножко посчитаем. Средняя скорость передачи данных среднего SATA диска — 160-180 МБ/сек при ширине интерфейса в 6 Гбит/с. Фактически, реальная скорость передачи данных с HDD не превышает 2 Гбит/с. Не такая уж большая цифра, учитывая, что связь мы планируем по 4м гигабитным портам (как именно превратить 4x1Гбит в 4 Гбит — обсудим далее). Намного хуже все со скоростями произвольного доступа — здесь всё падает чуть ли не до уровня дискет.
Учитывая, что профиль дисковой нагрузки от множества гостевых ОС — далёк от линейного, хотелось бы видеть более веселые цифры. Для исправления ситуации в файловой системе гипервизора ( VMFS v6) размер блока составляет 1 МБ, что способствует уплотнению множества случайных операций и ускоряет доступ к данным на виртуальных дисках. Но даже с этим одного физического диска будет недостаточно для обработки операций ввода-вывода от всех «гостей».
Сразу оговорюсь — всё дальнейшее имеет смысл, если у вас адаптеров для «сети хранения» больше двух. ESXi с бесплатной однопроцессорной лицензией умеет подключаться, кроме локальных дисков, к хранилищам двух типов — NFS и iSCSI. NFS предполагает доступ файлового уровня и тоже по-своему хорош. На нем можно развернуть гостей, нетребовательных к дисковой производительности. Бэкапить их — одно удовольствие, т.к. можно открыть эту же NFS шару ещё куда-либо и копировать снапшоты вм. В общем, с одним сетевым интерфейсом (если это не 10GE, конечно) — NFS ваш выбор.
У iSCSI есть ряд преимуществ перед NFS. Для того, чтобы реализовать их в полной мере, мы уже подготовились — заложив для сети хранения аж 4 гигабитных порта. Как обычно происходит расширение пропускной способности сети при известной скорости интерфейсов? Правильно, агрегацией. Но для полной утилизации агрегированного канала нужен целый ряд условий, и это подходит больше для связи коммутаторов между собой либо для сетевого аплинка гипервизора. Реализация протокола iSCSI предусматривает такую функцию, как multipathing (дословно, много путей) — возможность подключения одного и того же тома через разные сетевые интерфейсы. Само собой, про возможность балансировки нагрузки там тоже есть, хотя основное назначение — отказоустойчивость сети хранения. (Справедливости ради, NFSv4.1 поддерживает session trunking на базе совершеннейшей магии типа RDMA и MPTCP, но это попытка переложить проблемы файлового доступа с больной головы на здоровую на нижние уровни.)
Итак, для начала опубликуем наш таргет. Считаем, что FreeNAS установлен, IP-адрес управления исправно отгружает нам web-интерфейс, массив и zvol на нём мы нарезали в полном соответствии с нашими внутренними убеждениями. В нашем случае это 4 х 500ГБ диска, объединённых в raidz1 (что даёт всего 1,3 ТиБ эффективной ёмкости), и zvol размером в 1 ТБ ровно. Настроим сетевые интерфейсы i350, для простоты принимаем, что все будут принадлежать разным подсетям.
Затем настраиваем iSCSI-шару методом «Next, Next, Done». При настройке портала не забываем добавить туда все сетевые интерфейсы, выделенные для iSCSI. Выглядеть должно примерно так, как на картинках.
Чуть больше внимания потребуется уделить настройке extent — при презентации тома необходимо форсировать размер блока 512 байт. Без этого инициатор ESXi вообще отказывался опознавать презентованные тома. Для верности лучше отключить проброс размеров физ блока (которого на zvol нет и быть не может) и включить режим поддержки Xen.
С FreeNAS пока всё.
Особое внимание при настройке сети под iSCSI уделяем параметру MTU. Это как раз тот случай, когда «размер имеет значение» — берём максимум, который позволяют установить все компоненты сети. Если карточки соединены напрямую, можно указать mtu 9000 на обоих сторонах, на ESXi и FreeNAS. Впрочем, нормальные коммутаторы это значение поддержат. Пингуем, видим, что сеть у нас в норме, и пакеты требуемого размера проходят. Отлично. Поджигаем инициатор.
Включаем iSCSI, добавляем IP-адреса в динамическую секцию настройки (Storage -> Adapters -> Configure iSCSI -> Dynamic targets). После сохранения будет выполнен опрос iSCSI порталов по этим адресам, инициатор определит, что за каждым из них стоит один и тот же том, и подключится к нему по всем доступным адресам (тот самый multipath). Дальше нам потребуется создать datastore на появившемся устройстве.
После этого можно раскатать виртуальную машинку и замерить, что у нас получилось.
Не такие уж впечатляющие результаты. Открываем консоль хранилища, выводим текущее состояние сети и запускаем тесты.
Утилизирован лишь один сетевой порт из четырёх (igb1). Происходит это потому, что механизм балансировки, предусмотренный по умолчанию для multipath, с каждым пакетом данных выбирает один и тот же адаптер. Нам же надо задействовать из все.
Подключаемся к гипервизору по SSH и командуем.
Для начала глянем, какой ID у луна с multipath, и как он работает:
[root@localhost:~] esxcfg-mpath -b
naa.6589cfc000000b478db42ca922bb9308 : FreeNAS iSCSI Disk (naa.6589cfc000000b478db42ca922bb9308)
[root@localhost:~] esxcli storage nmp device list -d naa.6589cfc000000b478db42ca922bb9308 | grep PSP
Path Selection Policy: VMW_PSP_MRU
Политика выбора путей — MRU, то бишь most recently used. Все данные идут в один и тот же порт, перевыбор пути происходит только при недоступности сетевого соединения. Меняем на round-robin, при которой все интерфейсы меняются по очереди после какого-то числа операций:
[root@localhost:~] esxcli storage nmp device set -d naa.6589cfc000000b478db42ca922bb9308 -P VMW_PSP_RR
Перезагружаем ESXi, открываем мониторинг, запускаем тесты. Видим, что нагрузка распределяется по сетевым адаптерам равномерно (как минимум, пиковые значения, лишнее поскипано), результаты теста тоже повеселее.
Есть некоторые отклонения по портам, это возникает из-за лимитов Path Selection Policy — числа операций либо байт, после которого происходит переключение на другой порт. По умолчанию 1000 IOPS, то есть если обмен данными уложился в 999 операций — он пройдет через один сетевой порт. Можно менять, сравнивать и подбирать подходящее значение. Можно не менять, дефолта достаточно для большинства задач.
Делаем замеры, тестируем, работаем. Полученные результаты ощутимо превосходят возможности одиночного диска, так что теперь наши виртуальные машинки могут не толкаться локтями на операциях ввода-вывода. Итоговые значения скоростей и отказоустойчивость массива будут зависеть от железа и того, как выполнена конфигурация тома.
Уверен, что каждый системный администратор сталкивался с вопросом какой raid массив использовать для той или иной задачи. Хочу поделиться своими мыслями, цифрами и рассуждениями на эту тему.
Задача — планирование места для размещение виртуальных машин на системе хранения данных.
Используемое аппаратное и программное обеспечение для тестирования — VMWare ESXi 5.5 на HP ProLiant DL380 Gen8, виртуальная машина Windows 2008 R2 Enterprise (2 CPU, 4 Gb RAM, 60 Gb HDD), дисковая система HP P2000 G3 MSA FC, диски HP SAS 600Gb 10k, программа оценки скорости Cristal Disk Mark.
Цель — подбор типа raid массива.
Методика тестирования — включили виртуальную машину на локальном датасторе, смигрировали на массив, сделали замер, смигрировали обратно, на СХД размонтировали массив и из тех же дисков собрали другой тип рейда, смигрировали машину (VMWare позволяет это делать на горячую, без остановки машины), произвели замер, и т.д.
Выводы — всегда понятнее манипулировать цифрами. В интернетах много картинок что «быстрее», «отказоустойчивее» и т.д. Отказоустойчивость более понятный параметр — 1 или 2 диска, время восстановления после замены диска требует отдельного исследования. Картинки «попугаев» и прочих животных по конкретным дискам так же не очень подходят под нашу задачу, по скольку многое зависит от raid-контроллера.
В этой статье рассматриваем параметр «быстрее». Понимаю, что все зависит от конкретного железа, по этому указываю точную конфигурацию.
Результат — после проведения замеров для себя определили использование массивов Raid50 и Raid10.
Чтобы не быть голословным прикрепляю картинки замеров.
Raid0 на 4 дисках:
Raid0 на 12 дисках:
Raid10 на 4 дисках:
Raid5 на 9 дисках:
Raid50 на 8 дисках:
Raid6 на 4 дисках:
Слева на право: raid50, raid6 (2 измерения в разное время), raid5, raid10. Внизу справа: raid0 4 disk, raid 0 12 disk:
My question is whether I should go with RAID1/RAID10 or RAID1/RAID1/RAID1?
The VM's are as follows:
- MOSS front end for 100 users
- MOSS SQL backend for 100 users
- IIS Website very low traffic
- TOMCAT website very low traffic
- CRM Application that sync contacts between our Exchange and ERP servers also not a brute
Any advice on what to put where to get the best performance out of MOSS would be appreciated.
Please note this is the only hardware I have available, we have a very tight budget and can't buy another server to host SQL so it has to stay virtualized.
Edit: Database is read intensive, very few writes. I think this helps the all RAID1 position
Читайте также: