Overview Robert's Rules of Exchange is a series of blog posts in which we take a fictitious company, describe their existing Exchange implementation, and then walk you through the de...
Updated Jul 01, 2019
Version 2.0
Blog Post
@Nils - SAN with iSCSI is still quite complex. You have to test with Jetstress such that you completely load your iSCSI network and make sure that you have the right bandwidth and that the disk subsystem can support the load from Exchange.
PLUS, typically these scenarios introduce a shared storage infrastructure where the actual SAN that the iSCSI connects the servers to is also serving storage for a large database like SQL or similar. How do you test against that? How do you model the IOPS of that SQL Server database? This is not trivial.
Bottom line is that this is supported. I know of customers using this (at the scale you are talking about). But, it brings complexity, and I am against bringing the complexity if you can avoid it. I have nothing against iSCSI per se, as long as the cost is reasonable and the performance tests show that you will get the performance required out of the storage. But I am against the complexity that it brings, at least where I can avoid it.
PLUS, typically these scenarios introduce a shared storage infrastructure where the actual SAN that the iSCSI connects the servers to is also serving storage for a large database like SQL or similar. How do you test against that? How do you model the IOPS of that SQL Server database? This is not trivial.
Bottom line is that this is supported. I know of customers using this (at the scale you are talking about). But, it brings complexity, and I am against bringing the complexity if you can avoid it. I have nothing against iSCSI per se, as long as the cost is reasonable and the performance tests show that you will get the performance required out of the storage. But I am against the complexity that it brings, at least where I can avoid it.