Wednesday, February 17, 2010

Traffic (QoS) control built into your EON ZFS storage

Your EON ZFS storage provides access to a lot of services, such as HTTP, HTTPS, SFTP, Firefly/daapd, AFP(AppleShare) and more. All of these services are available as a network resource. Wouldn't it be nice to be able to control or manage how different systems use these network resources, such as bandwidth?

Project Crossbow provides the controls to manage and virtual-ize network resources. The traffic controls (QoS) can be used to manage by transport (TCP, UDP, SCTP, iSCSI, etc), bandwidth limits, IP address and more.

For example, one could simply limit the amount of bandwidth the HTTP, HTTPS or SSH service can utilize. You could create virtual nics bound to your real interface and provide different levels of service and bandwith to these virtual or real nics. It allows for a very flexible storage setup where you can really manage the traffic and quality of service it delivers.

Let's do a simple 10Mbps bandwidth limit for HTTP via interface bge0 for a flow we will label httpflow. First, we create a flow that matches the HTTP service
flowadm add-flow -l bge0 -a transport=tcp,local_port=80 httpflow
Let's view it
flowadm show-flow
Finally, let's set bandwidth limits
flowadm set-flowprop -p maxbw=10m httpflow
To verify the properties
flowadm show-flowprop
To show traffic usage
flowadm show-usage
Accounting can also be setup to record the usage. Rather than rehash the numerous possibilities, here are 2 links that details this feature fairly well. The first is written by Ben Rockwood and the other can be found here. Traffic control ... out!


zhangyibin said...

Crossbow is another cool technology provided by Opensolaris!!

BTW, I'm curious about next EON release, any hint?

Andre Lue said...


Next release is EON 0.60 based on snv_130, it is pending solving an AD integration problem that a user pointed out.

Reuben said...

This is wicked!

I was wondering if the next release of EON will have GD for PHP complied into it?

Cheers for your hard word.

Andre Lue said...


I'm not sure because GD is made up of many packages that present a challenge for the core image. I will revisit it from a binary kit inclusion.

Which features in GD are you looking to use and why? (all, jpeg, png. xpm, nice fonts)

Reuben said...

Thank you for response. I am designing an interface from the ground up and I would like to be able to create images on the fly (jpg,png) with text.


Andre Lue said...


I'll see what can be done. Would this be be effective if libphp was shifted out of the core image to the binary kit?

With all the added dependencies libphp reaches 12Mb+ which is considerate in comparison to total image size.