The trouble I find with the term 'Best Practices' is that they become
adopted as hard and fast RULES and this inevitably means that customers
become inflexible and won't explore the options.
LDoms are very flexible about a lot of things, best practices tend to
put barriers in place that may give a less than complete picture of LDom
capabilities.
I'd call these 'Starting Points', a basis for further exploration to see
if increasing or decreasing the settings gives improvements, a tuning
process any serious customer should be encouraged to go through to get
the best out of a system (virtual or not).
So...
- 1 core per LDOM is a reasonable starting place, the minimum
requiorements is one VCPU (one thread) per LDOM. There are a few reasons
for starting at 1 core (4 ot 8 threads/VCPUs)...
- optimal use of L1 cache on an execution unit (pronbably not going
to give you huge performance benefits, but for that last couple of
percent...)
- if the domain also has MAU's allocated to it, to get the maximum
performance from the MAU, you want a wide path to the MAU, that comes by
utilising more than one thread to get work to the MAU on that core,
since MAU's can't be shared (today) amongst other domains, you may as
well give ALL the threads on the core to the domain in order to get the
best from the MAU resource.
- Most domains are 'big enough at 8 thread (a full core), so
allocating full cores allows you to more easily keep track of which
threads/cores/sockets are being used by a domain, on a multi socket
server its possible that threads belonging to a single domain could be
allocated from more than one core or even from more than one socket, in
that case there is a possibility of increased socket-socket cache
coherency transactions resulting in a performance impact... again,
likely to only be single digit percentages, using nice round full core
count thread allocations could help you avoid that situation.
- Memory can be allocated in 8kb chunks, but Solaris is likely to need
at least 1GB to install and run happily (unless its a pretty minimal
install with insignificant applications installed), so allocating memory
in 1Gb chunks makes sense it also makes the math easier to figure out
how much memory is available or used.
- In your primary domain if you are making heavy use of ZFS it would
probably benefit from having larger amounts of memory, 4GB to start and
more if available....again, not hard and fast, but sensible.
- In general most operating systems perform better if they have more
memory, allocate as much as possible, if its available Solaris will try
to take advantage of it, share out the available memory in appropriate
ways dependent on the applications/demands running in each domain.
- IO services to guest domains....again the options are many and
varied... best practices are a 'situation dependent' entity.
- If I have SLA's I need to maintain in a guest domain, then I need
to make sure that the IO/Service domain that is providing a virtual
devices to my guest domain(s) is sufficiently powerful(memory/CPu
count/physical IO) to satisfy the IO demands of all of those guest domains.
- I may be better served to have multiple Services in the IO/Service
domain to allow me to separate the traffic from critical guest domains.
- It may be better to have multiple IO domains (if reasonable on the
architecture of the server) and dedicate totally separate IO domains to
specific guest domains IO requirements, this allows me to guarantee
separation and a minimum bandwidth that is not shared.
- Should I implement multi-pathing for the IO devices supplied to my
guest domains ?... multipathing often has some performance penalty to
pay but if reliability is my metric of choice, then thats a payoff I
should consider. IPMP is the typical means to achieve this with network
devices, various volume managers such as ZFS, VxVM, SVM are all options
to multipath to disks, you can also take advantage of MPxIO in FC-AL
enabled IO domains.
The choices go on, the key is to ask the right questions and learn how
to implement them with Solaris and the virtual services that LDoms
enables you to set up...
Peter
Paul Roberts wrote:
> Unofficially, I've heard you shouldn't go below 1 core per LDOM. Can
> anyone explain the limitations or best practices regarding hardware
> requirements for LDOMs? I'm curious what happens if you go by the thread...
>
> Regards,
>
> Paul
>
> --
> ______
> /_____/\
> /_____\\ \ Paul Roberts
> /_____\ \\ / Sun Microsystems, Inc.
> /_____/ \/ / / Sun Serviceability and Readiness Ops
> /_____/ / \//\
> \_____\//\ / / email: p.roberts at sun.com
> <mailto:p.roberts at sun.com>
> \_____/ / /\ / direct: 877-477-7642
> \_____/ \\ \
> \_____\ \\
> \_____\/ http://www.sun.com <http://www.sun.com/>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ldoms-discuss mailing list
> ldoms-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Peter A. Wilson Email: Peter.A.Wilson at sun.com
Snr. Technical Marketing Engineer Phone: (650) 786 0526 / x80526
SG Technical Marketing Cellphone : (408) 666 9320
Sun Microsystems, Inc. Fax : (650) 786 9553
16 Network Circle Mail Stop : MPK16-211
Menlo Park CA 94025 Office : MPK16-2468
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
