tag:blogger.com,1999:blog-5976686513564131325.post5870892165254651834..comments2024-03-17T15:34:05.492-06:00Comments on MPECS Inc. Blog: SBS 2K3 R2 - Setup steps and resources.Philip Elder Cluster MVPhttp://www.blogger.com/profile/06082028960643490292noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5976686513564131325.post-22887898100985138032007-07-13T13:57:00.000-06:002007-07-13T13:57:00.000-06:00Good point ... memory has a way of fading a bit ;0...Good point ... memory has a way of fading a bit ;0) And in this heat, my default brain move was recovery over performance. My bad. :)<BR/><BR/>Performance on a physical device can only go so far.<BR/><BR/>In the days of SCSI and now SAS, having multiple partitions on one drive or array would make some sense. SCSI/SAS can process multiple requests with SAS totally kicking SCSI's butt in performance today.<BR/><BR/>However, on the SATA platform where NCQ which is supposed to work like SCSI command queuing, but doesn't really do the job, having more than 2 partitions on one drive/array set is bad practice. The drives can only do so much before performance is compromised, and heads dancing across the platters to three different locations in the case of 3 partitions doesn't really work well.<BR/><BR/>So, on the bigger SBS servers we do the following:<BR/>RAID 1: C: (System), S: (Swap).<BR/>RAID 1: G: (VSS images), server storage. Exchange dbs here too.<BR/>RAID 5: H: Client Data, Company shared folder (WSS does not work for 300GB+), Users folders, Client<BR/>Apps, etc.<BR/><BR/>In the era of cheap SATA storage (1TB drives in the pipe now at less than $500), there is no reason why one would not utilize those 6-10 Hot Swap bays. The above configuration would be 10 drives with a Global Hot Spare.<BR/><BR/>The example used in the blog post is a small client SBS box, 2 x RAID 1 arrays. The second array is used for client data. VSS images are shifted to the C:. Exchange dbs stay in the default location on the system partition. More memory is better for Exchange's hungry memory caching.<BR/><BR/>In a production SBS box of at least 10 users do the following if you have not already done so:<BR/>Open Task Manager<BR/>Click View<BR/>Select Columns<BR/>Click the following (I forget which ones are there by default so excuse any duplication):<BR/> PID<BR/> CPU Usage<BR/> CPU Time<BR/> Memory Usage<BR/> Memory Usage Delta<BR/> Peak Memory Usage<BR/> I/O Read bytes<BR/> User Name<BR/> Virtual Memory Size<BR/> I/O Write Bytes<BR/> I/O Other bytes<BR/>Click OK<BR/><BR/>Now have a look at the data. After looking at these lists over the years, one can determine which processes are the most hungry for memory, Store, and which are more I/O intensive.<BR/><BR/>You can click on the columns to sort by the respective data set to further get an idea of what is happening on the server at any given time.<BR/><BR/>Sysinternals also has some pretty good utilities to check into what is what in the server processes.<BR/><BR/>That help to further develop my somewhat heat-stroked thinking processes! :D<BR/><BR/>PhilipPhilip Elder Cluster MVPhttps://www.blogger.com/profile/06082028960643490292noreply@blogger.comtag:blogger.com,1999:blog-5976686513564131325.post-51733362656396586352007-07-13T13:00:00.000-06:002007-07-13T13:00:00.000-06:00Philip,Essentially as a performance best practice....Philip,<BR/><BR/>Essentially as a performance best practice. One can argue that in a small environment, the gains would be irrelavent, but even if that were so, is there any reason to NOT put the database file where the SQL database and User Files are? What makes it any more "KISS" by keeping it on the OS partition.<BR/><BR/>BTW, I am not arguing against putting it on the OS partition, I really want to know and learn. :-)<BR/><BR/>-Alex<BR/><BR/>AMDGAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5976686513564131325.post-72227433297739255742007-07-13T12:30:00.000-06:002007-07-13T12:30:00.000-06:00Alex,That is a tough one to answer since it comes ...Alex,<BR/><BR/>That is a tough one to answer since it comes via many years of experience recovering sometimes insanely toasted drives and arrays.<BR/><BR/>Sometimes, the KISS principle - Keep It Simple Stupid - goes a long way towards getting things back on track.<BR/><BR/>I have read some of the justifications for moving the Exchange dbs to separate partitions ... however, in a worst case scenario where the SBS box has gone completely sideways and the backups are toast - <I>you do verify your backups right</I>? - you can still fall back on the Outlook client export or OST to at least get e-mail/contact/calendars both private and public folders back.<BR/><BR/>There is no replacement for off-site <I>proven</I> backups. Period.<BR/><BR/>Client production can resume with two essential elements in place: Data & E-mail. Server recovery proceeds from there ... whether by Swing if you have a second DC, by backup recovery which has its own caveats depending on the age of the backups, and now possibly via StorageCraft's ShadowProtect products. The last one is in the process of being tested and is looking very promising.<BR/><BR/>What are your thoughts on the matter?<BR/><BR/>PhilipPhilip Elder Cluster MVPhttps://www.blogger.com/profile/06082028960643490292noreply@blogger.comtag:blogger.com,1999:blog-5976686513564131325.post-74510850521949745582007-07-13T10:48:00.000-06:002007-07-13T10:48:00.000-06:00Excellent post, Philip.One question I have for you...Excellent post, Philip.<BR/><BR/>One question I have for you:<BR/>Why don't you place the Exchange Database in the same drive that he User Files are located? I only ask because every book I've ever read seems to suggest doing so.<BR/><BR/>-Alex "Achito" Tunon<BR/><BR/>AMDGAnonymousnoreply@blogger.com