Girish Moodalbail wrote:
On 07/21/10 08:52 PM, Artem Kachitchkine wrote:
I am sponsoring this fast-track for Mark Haywood. Minor binding is
requested. Timeout is set for 07/29/2010.
-Artem
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates.
All rights reserved.
1. Introduction
1.1. Project/Component Working Name:
SMF service for in.mpathd
1.2. Name of Document Author/Supplier:
Author: Mark Haywood
1.3 Date of This Document:
21 July, 2010
4. Technical Description
Overview
--------
Today, in.mpathd(1m), the daemon that performs failure and repair
detection for IP interfaces that have been placed into an IPMP group
is started via fork(2)-exec(2) by ifconfig(1m) on-demand when an IPMP
group is created (or by svc:/network/initial if all IP interfaces on
the system are being monitored). The daemon is being run in
environments where network robustness is a high priority. As such,
having the daemon managed by SMF infrastructure and taking advantage
of SMF's restarter facility seems like a better choice than the current
ifconfig mechanism which cannot provide as high a level of availability
of the daemon as SMF.
The current design has already been problematic enough to have been
addressed within the Sun Cluster consolidation. PSARC/2005/142
introduced an SMF service that manages in.mpathd on Sun Cluster
systems. At the time that PSARC/2005/142 was presented, we resisted
implementing an SMF service to manage in.mpathd as part of core Solaris
because we felt that we needed to see how the Clearview IPMP
rearchitecture panned out before doing this work. The Clearview IPMP
rearchitecture has been completed and is no longer an issue.
Additionally, a concern at the time was that in.mpathd was not an ideal
fit for being managed by an SMF service because in.mpathd only needs to
be running (enabled) when IPMP groups are configured on the system.
This is still true. However, IPMP use by our customers has increased
to the point that we now believe that over two-thirds of our Enterprise
customers are running their systems with IPMP configured. Though the
fit might not be perfect, there is no technical reason not to have
in.mpathd controlled by an SMF service.
Proposal
--------
Replace the Sun Cluster consolidation SMF service introduced by
PSARC/2005/142 with an ON consolidation service whose sole
responsibility will be to ensure the availability of in.mpathd.
The Sun Cluster group was notified. The contract associated with
PSARC/2005/142 will be terminated.
Details
-------
in.mpathd will be managed by smf(5) under the service identifier,
svc:/network/ipmp. The service will support a single instance,
svc:/network/ipmp:default, that will be enabled by default and will
support start, stop and refresh methods.
solaris.smf.manage.ipmp authorization allows users to enable/disable
the service and will be added to the Network Management execution
profile. The SMF manifest for the service is included below.
<service_bundle type='manifest' name='SUNWcsr:ipmp'>
<service
name='network/ipmp'
type='service'
version='1'>
<create_default_instance enabled='true' />
<single_instance/>
<dependency
name='network'
grouping='optional_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/milestone/network' />
</dependency>
Mark,
Had a quick clarification question on the dependency you have
specified above for the new svc:/network/ipmp. Don't we need this
daemon much before we reach the milestone/networ? I mean, while
re-configuring IPMP interfaces during boot from net-physical script?
It is possible that the dependencies may have to change once I do some
further testing. I did not mean to imply by including the service
example in the case, that the dependency list was set in stone. That
said, I'm not sure that in.mpathd has to start before net-physical. In
fact, as was mentioned earlier in this thread, in.mpathd today supports
an 'adopt' option that was supposed to handle the case where in.mpathd
cannot be executed during net-physical. The option is for historical
reasons and should not be relevant any longer. In any case, as things
stand, IPMP groups can be created before in.mpathd is running so I think
the answer to your question at this point is no.
Mark
thanks
~Girish
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
