Hi Edward,

Could you please check the following figure if you could see if this will work? The majority of the design was based on your book. I am not sure how can I implement the DMZ ISCSI and is this going to work with vMotion?
Biniam

Hello,

I have only one ISCSI and with software Initiators. We will have our portal and Front End exchange server on dmz and i need these two servers with high availablity; vMotion

Regards

Biniam

Hello,

I am using ESX software initiator.

Regards

Biniam

On last question Edward,

The IP addresses that you set when you configure the SAN. Are these IP number the same when you setup vmware iSCSI?

I that possible to have the VLAN on pSwitch only?

VM VLAN on the pSwitch

vMotion VLAN on the pSwitch

SC VLAN on the pSwitch

ISCSI VLAN on the pSwitch

Regards Biniam

Hi Edward and all,

I am back and I have all the kit to test what we discussed. I have some questions with regards to infrastructure and security.

I have installed the ESX hosts on 10.44.1.0/24 Vlan 10 also I have

2 pNIC for Service Console 10.44.1.0/24 Vlan 10
2 pNICs for VMs 10.44.2.0/24 Vlan 20
2 pNIC for vMotion 10.44.99.0/24 Vlan 99
2 pNICs for iSCSI 10.44.3.0/24 Vlan 30

I am Using EST (External Switch Tagging) with firewall controller access between the VLANs. Could you please tell me which VLANs need to see each, for VMware infrastructure to work in secure and efficient way?

Regards
Biniam

Assuming you have eight pNICs per host here's what I would do.

1) I would use the same two pNICs for both the service console AND Vmotion and I would route all traffic over VLAN10.
2) I would install the iSCSI initiator on the ESX host server and use two pNICs and VLAN30 to route between the iSCSI SAN and the host server.
3) I would use two pNICs and VLAN20 to route traffic between all VM's and what I call "The outside world".
4) I would install the iSCSI initiator on the VM's and use two pNICS and VLAN99 to route iSCSI traffic between the iSCSI SAN and the VM's.
5) I would divide my iSCSI SAN into two sections. One section would be formatted as VMFS and would be used to store all .vmdk files. These .vmdk files would contain only the VM guest OS (C:\ drive). Assuming you are using Windows OS within the VM's, I would format the other section of the iSCSI SAN as NTFS and allocated this space to the individual VM's which would be used to store the data.

While this is not necessarily the correct way to configure this environment, it is what I would do. Attached is a .png file which outlines what I stated above.

Jason

Hello,

The bottom looks great.


The Service Console must partiticpate in the iSCSI network in order for authentication protocols to work. This is required whether you use hardware iSCSI- HBAs or network cards. So your iSCSI device must see your service console and visa versa.


Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

Hello,

If you want your VMs to see your iSCSI network then they also must participate in this. I however recommend that the VM access and the Host access be segregated some how. If you only have your VMs access the iSCSI server and you have no other remote storage then vMotion will not work. Consider this:

VM only access to iSCSI using iSCSI initiator.... Where does the boot disk live? On local storage.... So therefore no vMotion.

VM and Host access to iSCSI using initiator within VMs and iscsi target within Host.... Could a VM then see any of the VMFS' on the remote storage? This depends on how the LUNs are presented, how the iSCSI server segregates such traffic. Does your iSCSI server support multiple network links? If so you may want to use a set of links for hosts and a set of links for initiators. If the Host uses iSCSI then an SC connection must be part of this network. How would such access impact disk performance at the Host level. Or impact the VM networks. With only 10 pNICs and 2 assigned to a DMZ, you could do this but you compromise security or redundancy on other networks. See previous discussions. If you have another set of pNICs then this would be a safe option. iSCSI is all about performance moving through the network to have VMs using iSCSI initiators they would need the network bandwidth for disk access. You can get the same backup/restoration behavior using Raw Disk Maps as well, which can use the Host based iSCSI target code. Either method works.

SC and vMotion in a truly secure environment should never be over the same vSwitch or pNICs. Yes people do it, but it really is insecure. However, this is mostly a trust related issue. If your administrators are allowed to login to the VMs then it is a moot issue as they have the credentials however if they are not allowed to login then allowing them access to the vMotion network could allow someone to gain those credentials quite easily just by capturing the data during a vMotion. Or if your SC is hacked and you are using remote login services a hacker can do the exact same thing. For full protection make it a private link.


Absolutely, lock down which machines have access to the Service Console, but nothing but an ESX server should have access to vMotion. If this laptop or any other host was compromised it can be setup to grab the memory image as it travels across the network during a vMotion and thereby gather credential data. I would not risk this.


Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization