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?
thanks
~Girish
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
