Thorsten Frueauf wrote: > Hi Robert et al, > > what you see is to be expected. If you configure the IP address > through SUNW.LogicalHostname, the zone flag can only be set once the > zone has booted. >
But one could imagine an extra smf service being deployed into a zone (and you already deploy couple of ther smf services into a zone) which would basically "suspend" booting until network is configured in. > If you still want the protection through SUNW.LH to trigger failover > in case an IPMP group is down, you would indeed need one in additional > IP per IPMP group. > Yeah, I know that's what I wrote in my first email. While it would work I'm not really like it that much... > There are at least two alternatives: > > 1) if you configure a SUNW.LH resource, you should consider to manage > the applications needing that IP as a cluster resource as well. You > can use the sczsmf and/or sczsh components to achieve that. > that would be fine but as I wrote before sometimes I end up with syslogd failing as it can't resolve a remote host it is supposed to send messaged, or sshd failing as it can't bind... etc. All these issues can be relatively easy work-arounded but imho it should work properly out-of-the-box. > > So bottom line, if you configre an application to bind to a specific > IP, you would need to make sure that it is getting started after the > IP is available within the zone. > Which is the case automatically with zones without using Sun Cluster. Only when using zones with Sun Cluster and LH resource (in a supported way) the issue shows up. IMHO smf network should wait in this case which probably would be easiest to achive by introducing extra smf service withing a zone so system/log, sshd, etc. won't start until there is a network available. > Regards > Thorsten > > Robert Milkowski wrote: >> Hi, >> >> Thank you for looking into it and sorry for not enough details. >> >> Solaris 10 + patches, Sun Cluster 3.2, 2x T5220 nodes. >> >> I have a LUN presented from shared storage with a pool created on top >> of it, and one IP address. >> So I created a resource group, with HAStoragePlus resource with >> zpool=test >> Then another resource which is logicalhosstname (cllogicalhostname) >> with the IP address I got. >> >> So now we have a RG with two resources: storage (HAStorage+ with a >> zfs pool) and a network resource. >> >> Then I created a zone with its zonepath on the pool being managed by >> the resource created above. >> Zone configuration is populated on both nodes. The zone does not have >> any IP addresses configured in. >> >> >> Now I created another resource to manage the zone (zone agent) with >> dependencies on network and storage by populating provided config >> file and using the register script (sczbt_register or something like >> this - don't have an access at the moment). >> >> >> Now if I bring entire resource group onlin the zfs pool will get >> imported, IP address will be set-up (in a global zone), zone will be >> booted and at some point the zone parameter will be set on a logical >> interface with the IP address so it "moves" into a zone. Generally it >> works fine - I can test a failover, failback and everything is >> perfectly fine except... sometimes the zone is booting quick enough >> so for example syslog is started before the cluster agent managed to >> move the IP address into a zone. But syslog has an entry to forward >> some messages to remote box and entry is a dns name without an entry >> in /etc/hosts so access to dns servers is required. But network is >> not yet set-up... or lets say sshd is configured to listen on the IP >> address and not on *:22 and sometimes it failes couple of times as it >> can't bind to IP address which is not there (yet). Thanks to smf it >> usually restarts couple of time and the IP address is configured in a >> meantime so stays up. However it went into maintaince mode once as >> after couple of retries (5?) smf gave up and put it in a maintaince >> mode as IP address still was not there. The sshd issue is not a big >> problem but it serves more as an example. The syslog issue is a real >> problem. >> >> Basically it looks like the IP address is being configured >> asynchronously to zone booting (after some stage is reached I would >> guess) and without holding other SMF services to start before it is >> done. So sometimes some services which depend on network will come up >> before the IP address is configured. >> >> I hope it makes more sense now. >> >
