On 6/28/06, Phil Freund <[EMAIL PROTECTED]> wrote:
I am constructing a fairly complex environment to provide high availability
using zones (containers), IPMP, Veritas Cluster Server, Veritas Volume Manager,
and Veritas File System. In this implementation, I am concerned both about the
high availability aspects and the maintainability aspects. I believe I have
solved most of the problems but I just realized that I need some advice
relative to the zone creation for the clustering environment.
What I believe to be true based on discussions with both Sun and Symantec:
- IPMP has no known issues. Network HA requires use of an IPMP managed network
interface in the zone definition.
IPMP does have problems if you are using link-based failure detection
and the groups of interfaces used by zones have no IP's used by the
global zone. See
https://www.opensolaris.org/jive/message.jspa?messageID=39767#39767
for details.
- DNS is used in both the global and non-global zones. (site requirement)
Sounds reasonable.
- The Release 4.1 versions of Veritas Volume Manager, File System, and Cluster
Server must be used on Solaris 10.
Right, more specifically you probably want to target MP1 or MP2 if it
is available within your timeline for initial deployment.
- Zone roots must be setup on UFS filesystems to allow them to be mounted for
patching and/or OS upgrades.
Seems to be least problematic of available options. If you are
specifically ruling out VxFS from zone roots, you should be ruling out
VxVM for zone roots for the same logic.
- Zone roots can be setup on SAN LUNs as long as the HBA drivers are in the
Solaris 10 DVD miniroot. This allows for OS upgrades. We are using the
Sun-branded Qlogic HBAs which are handled by the Leadville driver and is part
of the miniroot so this criterion is covered.
Zone roots should have nothing to do with HBA drivers. Zones do not
run their own kernel, and as such this a non-issue.
- In order to have multi-path failover on all of the filesystems defined both
on Solaris slices and Veritas Volume Manager volumes, we need to turn on MPXIO
and disable Veritas DMP. Otherwise the zone roots would not be protected from a
path failure.
I don't follow this one... It sounds like it may be based upon the
same misunderstanding from the previous bullet point.
- Identically named zones must be setup on each of the target nodes of a VCS HA
cluster in order for the nonglobal-zone-based applications to failover under
VCS. (per Symantec)
I had heard at one point that Symantec (that is so hard to say...) was
suggesting manual munging of /etc/zones/index, then encouraging a
zonepath to be deported from one server and imported on another. Sun
discourages this and is addressing the need (not quickly enough!!!!)
with zoneadm detach/attach.
I would suggest that part of your processes runs bart(1) against each
zone root to "fingerprint" each zone, then run bart compare on a
regular basis to protect against rot.
- The zone roots must be on locally mounted disk on each node to allow them to
be patched or upgraded while keeping the application(s) available on a
different target node. (per Symantec)
Sounds reasonable. This is obviously a different approach than I had
alluded to above.
- Performing patch or upgrade maintenance on a server hosting the zone requires
that the zone and its application(s) be failed-over to a different target node
and a cluster resource group freeze implemented. Once the maintenance is
complete and the patched/upgraded zone is rebooted (and then shut back down),
the cluster resource group can be unfrozen. This effort is then duplicated on
each of the target nodes until all of the servers have the same patches and/or
OS upgrades installed. (per Symantec)
Agreed.
Here's where I need advice:
Each of the failover-capable zones must have the same name on each hardware
node which in turn implies that they must use the same IP address, at least
when being setup initially. Once the zones are setup, is there any reason the
individual zone configurations cannot be modified such that each of the zones
has a different IP maintenance address on each hardware node? There would be
both a DNS entry for the failover zone name that matches a virtual address
managed by VCS and maintenance names for the zone addresses on each target node
to provide network accessability for testing after patching/upgrades. (Rather
like the maintenance addresses in an IPMP configuration.) If this is true, are
the only places that would need the changes implemented the zone xml file and
the entries in the zones /etc/hosts (and hostname.xxx) files?
It sounds to me like it may be be useful to just create each zone with
a unique hostname (and IP), then have a cluster resource that brings
the zone-specific IP online. Specifically:
server1# zonecfg -z zone1
add net
set address=server1-zone1.example.com
set physical=ipge0
end
(Yes, really I advocate putting the hostname in zonecfg - it makes it
so much more clear what you are intending. Zones start after the name
service and this supported configuration works just fine.)
The VCS resource would then perform the following when onlining the zone:
ifconfig ipge0 addif zone1 zone zone1 netmask + broadcast + up
The key thing to consider here is that outbound connections from this
zone may be coming from the zone1.example.com or
server1-zone1.example.com address. Plan firewall, TCP wrappers, etc.
rules accordingly.
This configuration would allow you to manually boot each zone on each
machine with no worries of IP conflicts (can't wait for zoneadm boot
-s nonet). As an added safeguard, you probably want VCS to be
responsible for starting the apps within the zones, rather than using
SMF or rc scripts within the zone. This will ensure that an errant
"zoneadm boot" doesn't cause multiple instances of the application to
be up at the same time.
Now, in the event that you don't want or need network connectivity
while the zone is not active on the node, you could configure the zone
without an IP address and use the ifconfig command above (through a
cluster resource) to bring the network up. This would likely offer
added "split brain" protection and get rid of the worries about
firewall, tcp wrappers, etc. mentioned above.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
