iSCSI with two DRBD primary nodes is a bad idea to use if the two paths get concurrent write requests. But I am thinking about using this idea as backend storage for an ESXi 5.5U2 host.
I already did test this with primary/secondary configurations and a classical failover-cluster.
What ESXi does at this point is that it detects a multipath und uses only one path actively. So in this constellation the concurrent write io-problem does not seem to arise.
Now the problem in both cases (primary/secondary or primary/primary) is: How do I shutdown an iSCSI server (iSCSI target provider in iSCSI terms) that has active open connections to an iSCSI client (iSCSI initiator in iSCSI terms)?
I currently use CentOS 5 on the target servers.
CO5 uses tgtd to provide the targets. To my astonishment the normal stop method fails, if there are connected clients. Instead the forcedstop seems to be what I need in this case.
I want to shutdown one server cleanly (I have to stop access to the target, so I can switch drbd to secondary) and the other server should then automatically become active (nothing to do there in this constellation IMHO).
Questions in that context: Is the following ok, or am I missing something?
- forced stop of tgtd (will first offline the targets)
- tear down IP into the direction of the initiator (different line than that used for drbd-replication)
- shutdown drbd (making it secondary first)
- reboot or shutdown server