2006-12-10 18:19:51 +01:00
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
|
|
<article>
|
|
|
|
<!--$Id$-->
|
|
|
|
|
|
|
|
<articleinfo>
|
|
|
|
<title>Scalability and Performance</title>
|
|
|
|
|
|
|
|
<authorgroup>
|
|
|
|
<author>
|
|
|
|
<firstname>Tom</firstname>
|
|
|
|
|
|
|
|
<surname>Eastep</surname>
|
|
|
|
</author>
|
|
|
|
</authorgroup>
|
|
|
|
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
|
|
|
|
<copyright>
|
|
|
|
<year>2006</year>
|
|
|
|
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
|
|
</copyright>
|
|
|
|
|
|
|
|
<legalnotice>
|
|
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
|
|
Texts. A copy of the license is included in the section entitled
|
|
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
|
|
License</ulink></quote>.</para>
|
|
|
|
</legalnotice>
|
|
|
|
</articleinfo>
|
|
|
|
|
|
|
|
<section>
|
|
|
|
<title>Introduction</title>
|
|
|
|
|
|
|
|
<para>The performance of the <emphasis role="bold">shorewall
|
|
|
|
start</emphasis> and <emphasis role="bold">shorewall restart</emphasis>
|
|
|
|
commands is a frequent topic of questions. This article attempts to
|
|
|
|
explain the scalability issues involved and to offer some tips for
|
|
|
|
reducing the time required to compile a Shorewall configuration and to
|
|
|
|
execute the compiled script.</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
<section>
|
|
|
|
<title>Host Groups</title>
|
|
|
|
|
|
|
|
<para>In this article, we will use the term <firstterm>host
|
|
|
|
group</firstterm> to refer to a set of IP addresses accessed through a
|
|
|
|
particular interface. In a Shorewall configuration, there is one host
|
|
|
|
group for:</para>
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>Each entry in <filename>/etc/shorewall/interfaces</filename>
|
|
|
|
that contains the name of a zone in the first column.</para>
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>Each entry in <filename>/etc/shorewall/hosts</filename>.</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
<para>As you can see, each host group is associated with a single
|
|
|
|
<firstterm>zone</firstterm>.</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
<section>
|
|
|
|
<title>Scaling by Host Groups</title>
|
|
|
|
|
|
|
|
<para>For each host group, it is possible to attempt connections to every
|
|
|
|
other host group; and if the host group has the <emphasis
|
|
|
|
role="bold">routeback</emphasis> option, then it is possible for
|
|
|
|
connections to be attempted from the host group to itself. So if there are
|
|
|
|
<emphasis role="bold">H</emphasis> host groups defined in a Shorewall
|
|
|
|
configuration, then the number of unique pairs of (<emphasis>source host
|
|
|
|
group</emphasis>, <emphasis>destination host group</emphasis>) is
|
|
|
|
<emphasis role="bold">H</emphasis>*<emphasis role="bold">H</emphasis> or
|
|
|
|
<emphasis role="bold">H</emphasis><superscript>2</superscript>. In other
|
|
|
|
words, the number of combinations is the square of the number of host
|
|
|
|
groups and increasing the number of groups from <emphasis
|
|
|
|
role="bold">H</emphasis> to <emphasis role="bold">H</emphasis>+1 adds
|
|
|
|
<emphasis role="bold">H</emphasis> + <emphasis role="bold">H</emphasis> +
|
|
|
|
1 = 2<emphasis role="bold">H</emphasis> + 1 additional
|
|
|
|
combinations.</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
<section>
|
|
|
|
<title>Scaling by Zones</title>
|
|
|
|
|
|
|
|
<para>A similar scaling issue applies to Shorewall zones. If there are
|
|
|
|
<emphasis role="bold">Z</emphasis> zones, then connections may be
|
|
|
|
attempted from a given zone <emphasis
|
|
|
|
role="bold">Z</emphasis><subscript>n</subscript> to all of the other zones
|
|
|
|
(including to <emphasis role="bold">Z</emphasis><subscript>n</subscript>
|
|
|
|
itself). Hence, the number of combinations is the square of the number of
|
|
|
|
zones or <emphasis
|
|
|
|
role="bold">Z</emphasis><superscript>2</superscript>.</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
<section>
|
|
|
|
<title>Scaling within the Shorewall Code</title>
|
|
|
|
|
|
|
|
<para>Shorewall is written entirely in Bourne Shell. While this allows
|
|
|
|
Shorewall to run on a wide range of distributions (included embedded
|
|
|
|
ones), the shell programming environment is not ideal for writing the
|
|
|
|
compiler portion of Shorewall. As a consequency, the code must repeatedly
|
|
|
|
perform sequential searches of lists. If a list has <emphasis
|
|
|
|
role="bold">N</emphasis> elements (<emphasis role="bold">N</emphasis> >
|
|
|
|
1) and a sequential search is made for each of those elements, then the
|
|
|
|
number of comparisons is 1 + 2 + 3 + .... + <emphasis
|
|
|
|
role="bold">N</emphasis> = <emphasis role="bold">N</emphasis> * (<emphasis
|
|
|
|
role="bold">N</emphasis> - 1 ). So again, we see order <emphasis
|
|
|
|
role="bold">N</emphasis><superscript>2</superscript> scaling.</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
<section>
|
|
|
|
<title>Improving Performance</title>
|
|
|
|
|
|
|
|
<para>Achieving good performance boils down to two things:</para>
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>Use a light-weight shell and fast hardware. Especially in the
|
|
|
|
compiler, a light-weight shell such as <command>ash</command> or
|
|
|
|
<command>dash</command> can provide considerable improvement over
|
2006-12-10 18:26:21 +01:00
|
|
|
<command>bash</command>.</para>
|
2006-12-10 18:19:51 +01:00
|
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>With all of the order <emphasis
|
|
|
|
role="bold">N</emphasis><superscript>2</superscript> scaling that is
|
|
|
|
implicit in the problem being solved, it is vital to keep <emphasis
|
|
|
|
role="bold">N</emphasis> small.</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
<para>So while it is tempting to create lots of zones through entries in
|
|
|
|
<filename>/etc/shorewall/hosts</filename>, such configurations
|
|
|
|
<emphasis>always</emphasis> perform badly. In these cases, it is much
|
|
|
|
better to have more rules than more zones because the performance scales
|
|
|
|
linearly with the number of rules whereas it scales geometrically with the
|
|
|
|
number of zones.</para>
|
|
|
|
|
|
|
|
<para>Another tip worth noting has to do with the use of shell variables.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>Suppose that the following appears in
|
|
|
|
<filename>/etc/shorewall/params</filename>: </para>
|
|
|
|
|
|
|
|
<programlisting>HOSTS=<ip1>,<ip2>,<ip3>,...<ipN></programlisting>
|
|
|
|
|
|
|
|
<para>and suppose that $HOSTS appears in the SOURCE column of <emphasis
|
|
|
|
role="bold">M</emphasis> ACCEPT rules. That would generate a total of
|
|
|
|
<emphasis role="bold">N</emphasis> * <emphasis role="bold">M</emphasis>
|
|
|
|
iptables ACCEPT rules.</para>
|
|
|
|
|
|
|
|
<para>On the other hand, consider the following:</para>
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
<para><filename>/etc/shorewall/actions</filename>:</para>
|
|
|
|
|
|
|
|
<programlisting>AcceptHosts</programlisting>
|
|
|
|
|
|
|
|
<para><filename>/etc/shorewall/action.AcceptHosts</filename>:</para>
|
|
|
|
|
|
|
|
<programlisting>#TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
|
|
|
|
# PORT PORT(S) DEST LIMIT
|
|
|
|
ACCEPT $HOSTS </programlisting>
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
<para>If the <emphasis role="bold">M</emphasis> ACCEPT rules are now
|
|
|
|
replaced with <emphasis role="bold">M</emphasis> AcceptHosts rules, the
|
|
|
|
total number of rules will be <emphasis role="bold">N</emphasis> +
|
|
|
|
<emphasis role="bold">M</emphasis>.</para>
|
|
|
|
</section>
|
|
|
|
</article>
|