Installing Exchange
-
What kind of tools do you keep in there? For tools, if they were not available online, it seems like FTP or HTTP would be good, too.
-
I was looking over the options I put into the MS worksheet. I didn't change my level 4 users from 1 GB to 200 MB. After doing so, the sheet now says I should use one DB.
But I still don't know what Database and Log Configuration / Server vs DB and Log Volume Design / Server is?
At my current listed maxes
6 users max 10 GB
14 users max 5 GB
65 users max 200 MB
Max total = 143 GBSo I more or less know where the left side numbers are coming from, where are the right side coming from? Is the additional size for a restore LUN? The 70 or so GB isn't enough to restore the DB into, assuming it's maxed out.
-
The storage design tab definitely seems antiquated as well. It does have the JBOD options that MS recommends when using DAGs, but when assuming bare metal install:
DB - RAID 1, two drives
Logs - RAID 1, two drives
Restore - RAID 5, three drives - WTF MS? are you really expecting me to use SSD?So the design is 7 drives.
As for a VM situation - the worksheet doesn't really seem to have any suggestions.
-
It's their recommendations assuming you were cutting big time corners from 1998. I'm not kidding, that's where those recommendations come from.
-
@scottalanmiller said:
It's their recommendations assuming you were cutting big time corners from 1998. I'm not kidding, that's where those recommendations come from.
yeah - this tool is damn near useless!
-
Well, you can have every user in their own database if you really wanted to. That would be horrid but you COULD do it.
IMO, you seem to have a small exchange server so one database for the users is enough. If you are into it, a seperate one for the archives.
I would also have these drives:
- OS
- mailbox database
- logs
- archive database (if you're doing that)
I think I'm probably repeating what's already been said.
-
@nadnerB said:
Well, you can have every user in their own database if you really wanted to. That would be horrid but you COULD do it.
i could only do that if I bought Enterprise edition - and that would be just crazy
-
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
-
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and nearly useless!
-
@Dashrender said:
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and nearly useless!
uhm..... I'd say drop the nearly on nearly useless.
-
@travisdh1 said:
@Dashrender said:
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and
nearlyuseless!uhm..... I'd say drop the nearly on
nearlyuseless.FTFY
-
@Dashrender said:
@scottalanmiller said:
The concept of splitting the database and logs is based on the antiquated thought that no one could possibly afford RAID 10 for the database and had to cut corners and get RAID 5. If you are not using RAID 5 on spinning disks, then your logs do not get split from the database. They perform better being on the same array, not two different ones.
So in my case, they aren't suggesting RAID 5, because I don't have a storage need? LOL - yeah this tool really is just old! and nearly useless!
Yeah, it's worse than useless, it is actively misleading. Pretty much for most Exchange current installs you can make due just fine with RAID 1 and done.
-
That's going to be my new phrase...
RAID 1 and Done.
-
@scottalanmiller said:
That's going to be my new phrase...
RAID 1 and Done.
Sounds like a new SMBITJournal article in the making, ha ha ha.
-
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
-
@PSX_Defector said:
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
OMG short stroking.... it's been forever since I heard people talking about that.
-
I always buy extra short cables to improve latency.
-
-
-
@scottalanmiller said:
@PSX_Defector said:
@scottalanmiller said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
What, you mean to tell me putting my database on the inside tracks of my disk is no longer valid? What about when I use my SSDs, surely they will appreciate the lower access time of being closer to the controller!
OMG short stroking.... it's been forever since I heard people talking about that.
Last time someone mentioned it to me was back in 2011. Had to correct the fool about the fact he was running on a huge HP 585 using 15K RPM SAS drives. Even if we could lay out the sectors that way, it was no longer applicable because the controller was the bottleneck at that point.
These old ass ways of thinking still permeate various circles. Especially in old school mainframe guys, the ones who don't giggle when you mention you once had a Wang.
