Re: [zones-discuss] static routes vs default routes (zones in different subnets)
On Sun, Nov 9, 2008 at 10:34 PM, Tommy McNeely [EMAIL PROTECTED] wrote:
The problem I ran into this time was that static routes don't seem to
use the same intelligence that default routes do. For example, in the
snip
At least as of 10U5 your observation is correct. I tried
getting Sun to recognize this issue via a support case, after 6 to 8
months of the case being opened, they told me that IP Exclusive was
the work around and that they would NOT even file a bug or an RFE on
the static route behavior. Unfortunately, this is a work around that
really hampers us due to the limitations of the number of physical
ethernet interfaces we can put in a single box (and the cabling mess
that goes with it). We have many different security requirements for
Internet exposed servers, none of which has a particularly high
load, so it makes sense to put them all on zones on a moderate server
from a load perspective.
If this has changed, or is being worked on in OpenSolaris, I
would *love* to hear about it.
snip
I know this would be made simpler with vnic and private IP stack, but
in my world, shared-ip is the only thing available (feasible).
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Facilities Coordinator, Albacon 2008
- Business Manager, Delta-Xi cast of Alpha-Psi-Omega @ RPI
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
On Mon, Nov 10, 2008 at 12:30 AM, Mike Gerdts [EMAIL PROTECTED] wrote:
On Sun, Nov 9, 2008 at 7:54 PM, Jeff Victor [EMAIL PROTECTED] wrote:
zonestat intro snipped
If you have any comments, or suggestions for improvement, please let
me know on this e-mail list or via private e-mail.
I've had such needs for a while and have developed some tools to help my
organization with that.
Unfortunately, I'm not able to share that code. I am able to share
suggestions...
I am in a habit of:
#! /usr/bin/perl -w
use strict;
Yes, those generated warnings when I had used them earlier. I wanted
to get the code out the door and took a couple of shortcuts to do
that. I will address the warnings soon and put those checks back in
place.
That catches a lot of mistakes that may be masked by:
close STDERR;
which I never do. :)
:-) Another of the short cuts. I hope to remove those short cuts in
v1.3, which should be done this week.
Please do not use /etc/release as a test of kernel functionality.
Those that patch to an equivalent level as the update release have a
similar level of functionality. A better mechanism would be to check
for specific kernel patches.
Great idea, I'll look into it.
# Get amount and cap of memory locked by processes in each zone.
# kstat -p caps:*:lockedmem_zone_* conveniently summarizes all zones for us.
#
open(KSTAT, /usr/bin/kstat -p caps:*:lockedmem_zone_* |);
while (KSTAT) {
You could just use Sun::Solaris::Kstat rather than forking another perl
script.
Yup, that was in the ToDo list: convert all uses of /usr/bin/kstat to
uses of the Kstat module. I might sneak that into v1.3 along with
significant improvements in identifying zone-project mappings.
My feeling on capped memory is that if it becomes an issue and capped
swap is not really close to capped memory, the over-consumptive zone
has too high of a chance of causing horrible I/O problems for all
zones. That is, the cap is likely to do more harm than good. This
may change if swap can go onto solid state disk. I only mention this,
because I don't see a purpose in capping RSS, rather I cap swap.
For fast leaks and DoS attacks, I agree. The RAM cap helps with slow
leaks and temporary overconsumption of RAM.
FWIW, I tend to use the term reserved memory instead of swap
because that is less confusing to most people.
That's a useful perspective. If you choose the swap cap - which is
really a VM cap - so that the sum of the swap caps is less than RAM,
you have effectively implemented 'reserved memory.' (I'm ignoring RAM
usage of the global zone, which shouldn't be ignored in practice.)
But you must be careful: nothing prevents you from 'over-reserving'
memory. If you have 'reserved' all of system memory in this way, and
add a new zone with its own 'reserve,' you will have over-subscribed
memory. That might be a good thing, as long as no one is surprised if
the system starts paging.
However, the entire concept of reserved memory limits the scalability
of the system. Imagine 4 zones with swap caps of 4GB, on a system with
16GB of RAM. (Again, I'm ignoring the GZ.) Unless you allow yourself
to over-subscribe RAM, you can't add more zones, even if those 4 zones
are only using 1GB each during normal conditions.
Balance is needed. When paging must be avoided at all costs,
'reserving' memory by setting proper swap-caps makes a great deal of
sense. When paging is unlikely because the workload is well
understood, and a small amount of paging would not be horrible, and
zone 'density' is important, reserving memory would not make sense.
Many situations would call for memory 'reservations' on some zones,
and RAM caps on others.
For CPU related stats, take a look at a discussion I started a while back:
http://mail.opensolaris.org/pipermail/perf-discuss/2005-November/002048.html
Cool. Also, Jim Fiori had a simple idea for counting CPU time per zone
with almost no perf impact: use DTrace to implement a probe which
fires every M microseconds, and increments a per-zone counter. But
that's a short-term solution. We need a per-zone counter in the kernel
that tallies CPU time per zone.
One project I would like to kick off sometime is doing per user, per
project, and per zone microstate accounting.
Excellent idea. I'll watch for it! :-)
snip
I didn't have a chance to check logic closely or run it on a test
system. I'll offer more feedback if needed when I get a chance to
test it. It is a great start and I can't wait to see it progress.
Thanks!
--
--JeffV
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
I am curious if you have plans to make it Solaris 10 compatible. -= Kevin =- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Victor Sent: Sunday, November 09, 2008 5:54 PM To: zones-discuss@opensolaris.org Subject: [zones-discuss] Zone Statistics: monitoring resource use of zones It has become clear that there is a need to monitor resource consumption of workloads in zones, and an easy method to compare consumption to resource controls. In order to understand how a software tool could fulfill this need, I created an OpenSolaris project and a prototype to get started. If this sounds interesting, you can find the project and Perl script at: http://opensolaris.org/os/project/zonestat/ . If you have any comments, or suggestions for improvement, please let me know on this e-mail list or via private e-mail. --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] static routes vs default routes (zones in different subnets)
On Nov 10, 2008, at 7:09 AM, Paul Kraus wrote:
On Sun, Nov 9, 2008 at 10:34 PM, Tommy McNeely
[EMAIL PROTECTED] wrote:
The problem I ran into this time was that static routes don't seem to
use the same intelligence that default routes do. For example, in the
snip
At least as of 10U5 your observation is correct. I tried
getting Sun to recognize this issue via a support case, after 6 to 8
months of the case being opened, they told me that IP Exclusive was
the work around and that they would NOT even file a bug or an RFE on
the static route behavior. Unfortunately, this is a work around that
really hampers us due to the limitations of the number of physical
ethernet interfaces we can put in a single box (and the cabling mess
that goes with it). We have many different security requirements for
Internet exposed servers, none of which has a particularly high
load, so it makes sense to put them all on zones on a moderate server
from a load perspective.
... hence my shared-ip is the only thing available (feasible)
comment :)
If this has changed, or is being worked on in OpenSolaris, I
would *love* to hear about it.
Network interface virtualization!
http://opensolaris.org/os/project/crossbow/
I think some of the deep dark kernel stuff is integrated to
OpenSolaris (and thus Solaris Express), but not everything yet?
~tommy
snip
I know this would be made simpler with vnic and private IP stack, but
in my world, shared-ip is the only thing available (feasible).
--
{1
-2-3-4-5-6-7-}
Paul Kraus
- Facilities Coordinator, Albacon 2008
- Business Manager, Delta-Xi cast of Alpha-Psi-Omega @ RPI
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
On Mon, Nov 10, 2008 at 11:21 AM, Young, Kevin [EMAIL PROTECTED] wrote: I am curious if you have plans to make it Solaris 10 compatible. I do all development on Solaris 10. The script makes an effort to distinguish between the different capabilities of the different Solaris 10 updates. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Victor Sent: Sunday, November 09, 2008 5:54 PM To: zones-discuss@opensolaris.org Subject: [zones-discuss] Zone Statistics: monitoring resource use of zones It has become clear that there is a need to monitor resource consumption of workloads in zones, and an easy method to compare consumption to resource controls. In order to understand how a software tool could fulfill this need, I created an OpenSolaris project and a prototype to get started. If this sounds interesting, you can find the project and Perl script at: http://opensolaris.org/os/project/zonestat/ . If you have any comments, or suggestions for improvement, please let me know on this e-mail list or via private e-mail. -- --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] slow transfer to branded zone
On Thu, Nov 06, 2008 at 11:40:33AM -0500, Mark Glidden wrote: Hi, Customer has S-10 server with a branded zone (S8) He tells me that rcp - or ftp transfers into the zone are extremely slow. The same transfer direct to the S10 global zone is fine, from the global zone to the branded zone is fine. From the branded zone outbound to another server is fine, it is only when transferring files from another host into the branded zone. Are there known issues here? not that i know of, and given my knowledge of our emulation layer, i can't really think of a reason why they'd be seeing this behavior. feel free to collect data and file a bug. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] FW: using load balancers with zones]
On 11/10/08 13:56, Steve Lawrence wrote: ... I am sure there must be a way to tell ipf to force packets from the be- net to the fe-net to go out on the wire, presumably using dup-to but I was unable to make it work, so I am using source-nat at the moment. I look forward to hearing that someone else has already figured this out and here is how they did it, but for now I need to work on installing software on mail-fe-1 because it was supposed to be working last Tuesday ;) I think the best answer to your question is to download the latest snapshot of a crossbow build and use that. What you need is local (on the zones box) switching that recognises packets don't need to leave the host to find the destination. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
