Edward,
Thank you for your quick reply.
+It can affectperformance as you are now pulling more data over the same link as youwere before. So yes, it could affect performance.+I can understand that from a pure load issue. What I meant is that is there a greater load placed on the servers merely from having to use two different storage protocols (NFS & iSCSI)? Or is it better to use iSCSI on the test/dev storage device so that we are only configuring and using one storage protocol?+Well that depends on how
you setup your IP storage network? If it was me, and I was concerned
about security, I would place the NFS server in its own security zone
and have new NFS only vmkernel portgroups on their own vSwitch
(dedicated pNIC) on my ESX hosts. This will lower the overall impact on
performance within the existing vmkernel IP Storage network. Also,
since NFS does not require participation by the SC as iSCSI does, you
do not cross security zones this way.+
+If your VMs must access this NFS store directly over the network
instead of indirectly through the CDROM interface within the VM, I
would 100% separate this from your other IP Storage. VMs are hostile
critters to the virtual environment.+
RHEL can be hardened quite handily using either the CISecurity Benchmark or Bastille-Linux. At the very least I would do this!
I think this gets to the heart of the matter. I am not sure using a full OS is the way to go for me. I am really a Windows admin and my knowledge of Red Hat is somewhat lacking. Based on that, it might be best to use a storage OS such as Openfiler or NexentaStor. Have you any opinion on which one is more stable and/or performs better?
IP Storage is one Security Zone, SC is another usually.
+iSCSI -> requires SC participation and depending on how you are
doing this, you may have created another attack point into the ESX
host.+
NFS does not require SC participation so NFS can not cross security zones....
How do the VMs access the ISOs?
Indirectly -> then use your normal IP Storage network
Directly -> then use a dedicated network
Also note that the use of VCB can also cross security zones, so that needs to be considered and used very carefully.
The VMs would access the storage indirectly though ESX. This device would be presenting storage to the ESX hosts. I believe I get what you are saying regarding security zones and how iSCSI provides an additional need for a SC, which is a security issue. However, my concern had more to do with the fact that this secondary storage device will have access to the storage network. Unfortunately we are limited in creating security zones and additional networks because I am in an university environment where individual organizations cannot change the network design or add security zones. We must leave a SC on the OP storage network, because it is not possible to route the IP storage network back to our main network. We must keep our IP storage network and vMotion networks on switches that are isolated from the main university networks to be complaint with them. Thanks.
