Hi Mike,
Thanks for providing valuable feedback. Apologies for the
delay in replying. My responses are in line.
Mike Gerdts wrote:
> On Tue, Jan 12, 2010 at 3:16 AM, sanjay nadkarni (Laptop)
> <Sanjay.Nadkarni at sun.com> wrote:
>
>> Caimanics,
>> Please review the requirements documents for replication in OpenSolaris.
>> This provides the the Flash type functionality but includes support for
>> zones.
>>
>> Thanks
>>
>> -Sanjay
>>
>
>
>> Archive: A compressed zfs send stream of the active
>> boot environment is defined as an archive.
>>
>
> s/A compressed/An optionally compressed/
>
I was thinking of always having default compression else the sizes might
be too big. Moving 5-10GB images is painful.
>
>> Master Image: The archive and the metadata for a specific
>> system is the the master image. This image can be used
>> to clone other systems.
>>
>
> s/clone other systems/create clone systems/
>
Okay.
> I like the idea of being able to more fully specify system
> configuration (e.g. network, partitioning) as part of the archive.
> However, it should be possible to override those. For instance, in a
> disaster recovery situation the hardware and/or target network may be
> different than the master.
>
The ability to override, name server and IP (i.e. system configuration
parameters) is a requirement. The thought here is provide information
that would be helpful when choosing a target system. I hate to use the
term QoS, but for lack of a better work, I thought it would be useful
to include the QoS associated with the image.
>> 4. Master images must support global and non-[global ]zones.
>>
>
> Does this mean that a master image must support all of the following
> combinations:
>
> - Global zone only
> - Global zone and one non-global zone
> - Global zone and more than one non-global zone
> - Non-global zone only
>
>
Yes. I will list them out as you suggest.
> I would find it useful to be able to deploy a flash-ish global zone in
> one phase, followed by deploying various non-global zones over time.
> Much like the architecture requirements, presumably these may need to
> do an "image update" during attach.
>
you mean replicating a zone ? So something like, cloning a zone,
detaching the cloned zone and attaching it to another system ?
>> 5. Master images created must be portable, i.e. the images need
>> to be in a compressed format. Multiple compression options
>> must be provided.
>>
>
> Not sure how compression relates to being portable.
>
> Compression is good, but it should be optional and the algorithm
> should be selectable based on user needs. In an environment with
> gigabit networks and Niagara CPU's, I am much more likely to select
> lzjb than bzip2 as compression algorithm. In a global WAN with Xeon
> CPU's bzip2 is probably the right compression algorithm.
>
> zfs send data streams can be deduplicated. In the case of a send
> stream having a global zone and one or more non-global zones (and some
> other scenarios) this may have more effect than even an aggressive
> compression algorithm.
> http://arc.opensolaris.org/caselog/PSARC/2009/557/
>
Thanks for pointing that out. This is will definitely help with zones.
> Disks are likely to get faster (as SSD comes down in price) while each
> CPU pipeline is not really getting much faster. Consideration should
> be given to file formats and algorithms that MT friendly. For
> example, http://compression.ca/pbzip2/. I highly suggest doing all of
> your work on Niagara system to help inspire thoughts in this line.
>
>
Good idea.
>> 7. Must provide the ability to add additional architecture
>> specific pkgs. This requirement is especially applicable to
>> SPARC. If a master image is created on specific SPARC
>> platform, and the image is applied to another SPARC
>> platform, then the tool must detect the platform
>> differences and have a method to accept platform specific
>> pkgs.
>>
>
> Doesn't this apply to x86 as well if the master lacked drivers that
> are needed on the clone system
>
Agreed. However, I was not thinking about this issue. We have a
project that will be delivering soon to provide the ability to provide
Driver Update during install. I need to think about the interaction
between this and master image.
> Just to be clear, this gets us out of the current problem with
> requiring separate flash archives for sun4u anad sun4v systems, right?
>
Yes.
>
>> Zone information: Number and types of zones. (?)
>> Per_zone_info (need to zero out guid info)
>> Name Service: Type of name service used ( NIS, DNS, LDAP)
>>
>
> Why not just leave the config files inside the zone alone rather than
> trying to capture them in some other format? I worry that otherwise
> the current disconnect with reality of only having one name service
> will be carried forward. That is, currently sysidcfg has no way to
> say to use DNS for hosts, LDAP for passwd and group, and files for the
> rest.
>
>
Dave had a similar question. I have provided a detailed reply there.
The short answer is, it's for informational purpose. I would like
feedback as to whether this is useful.
> General:
>
> The global zone and non-global zones may be in different pools. So
> long as the boot pool is limited to single disks or mirrors, it is
> quite likely that systems intended to host a lot of zones will have
> the zones in a pool other than the boot pool.
>
> If network metadata is contained in the archive, there needs to be a
> way to deal with different NICs in different machines. For example,
> one would think that a T1000 and T2000 are relatively the same.
> Unfortunately one has bge interfaces and the other has e1000g
> interfaces.
>
I definitely need to elaborate. My thought really was to capture if
network failover, or aggregation was enabled. With the introduction of
crossbow, one can create a complex network topology and the idea here
be able to capture that. If 3 VNICs were built by aggregating 2
physical NICs and then partitioning them. It would be nice if the
target system had 2 phyiscal NICs.
> Any support for incremental archives? Presumably this would leverage
> zfs send -I. It would be helpful for those cases where there is a
> very common base configuration with several variants built from that
> base.
>
Are you suggesting differential flash type functionality ? After
speaking to a number customers, very few used differential flash. When
used, it was to delivery patches. Since IPS addresses the patching, I
don't see need.
-Sanjay
