[OpenIndiana-discuss] New Zone User Questions

[Jim Klimov]

On 2013-02-05 10:34, DormitionSkete at hotmail.com wrote:
>
> On Feb 5, 2013, at 2:10 AM, Andrej Javoršek wrote:
>
>> Now you are moving from complex to "mind bogging complex"   :)
>> But yes with OI you can create network (datacenter) in a box (switches,
>> routers, servers):
>> http://www.c0t0d0s0.org/permalink/Upcoming-Solaris-Features-Crossbow-Virtualisation.html
>>
>> Regards
>> Andrej
>>
>
> Well, I just laid down to go to sleep, and it just clicked.  Is this what Ian means, to have a zone for our MySql, one for Apache, one for Tomcat, one for email, etc. ?  And using port forwarding to go to the appropriate zone?

Yes - for those zones that need it (I elaborate an example below).
For example, your database zone should not see the internet, only
the web-server needs that (Apache or Tomcat in your case, or maybe
both). And for this accessibility you only allow certain ports on
the firewall settings. In fact, with NAT in place, those ports that
you don't explicitly define for forwarding from outside connections
would have nowhere to go and would be dropped - adding somewhat to
your counter-internet security.

And do expect that your systems will be constantly scanned and at
least simple common break-ins will be attempted - not because there
are many malicious people that have something against you, but because
over time they gathered control over many sick PCs ("bots") and those
scan for targets on their own in spare time.

Don't use trivial passwords for anything that faces the internet ;)

> And I'm not sure I understand your comment about the Crossbow-Virtualisation -- yes, that'd be much more complex. But is what I said about hooking up additional hardware routers to do the port forwarding something that would work and would fall within the realm of reasonably accepted practices?
>
> And you all don't normally do the Crossbow Virtualization, right?

Actually, most of us do now without even noticing. For example,
the exclusive-IP zones require a dedicated NIC. Back when the
feature was introduced, it was limited to the physical network
adapters, or at most the VLAN pseudo-interfaces - one per NIC.

Now with Crossbow we can create VNICs which became the foundation
for the common use of exclusive-IP zones and a decline of use-cases
for shared-IP zones (basically, with alias addresses on a common
NIC between the GZ and several zones, with GZ's routing table
inherited into a zone - caused "interesting" problems when there
were different subnets and different default routers were needed
for the GZ and LZs, within one routing table, and a common set
of firewall rules in the GZ).

A further commonly used feature of Crossbow is etherstubs - you
can think of them as virtual ethernet switches to which VNICs
can be connected, so that services in zones can securely and
quickly interact over usual TCP/IP without packets ever hitting
the physical wire. This can be used for lab modelling of nets
with zones and VMs attached to different switches, as well as
for "production" use of the fruits of such experiments.

> I *think* I just made a leap in my head about all this stuff.
>
> It certainly would be easier to make zones for each of these services, rather than complex ones with many of them.  It kind of goes along with what we programmers do, breaking tasks down into small classes, etc.

Yes. It is now common for a website content management system
(CMS), such as Magnolia or to extent Alfresco, to rely on a
database, for example. You can set up MySQL (or PgSQL) in one
zone - or two for replicated redundancy - and their webserver
clients in another. This way even if there is a break-in to
your webserver zone, there are no database files to mangle
and corrupt. You can also manage their backups separately, and
with greater precision see what is your bottleneck if the server
no longer copes well with its load.

Note however that increasing complexity does add some latency
by itself, and in case of database-backed websites, you might
need some tricks to ensure that the HTTP server starts after
the DBMS server - this is easily solvable by SMF dependencies
within one environment, but harder to solve in separated setups.
Again, in this particular case your webserver would actually
be a Java application server and can by itself manage database
connection pools (instead of having the CMS webapp connect to
the DB directly) and thus delay its initialization until the
DB connection succeeds.


> Guidance, please?

I'd start with that page I posted on NAT for local zones.

As a further tip, since at least some of your zones are likely
going to be talking to the internet, and you have a phone-line
connection, you would most likely benefit from setting up a
"caching DNS server" (one of the most trivial setups, google
for that) in the zone which you use for NAT/routing tasks,
and publish it via DHCP or static config to your internal
zones - and maybe to the rest of your local net.

This way your systems would likely do less queries to the global
naming system, freeing up the bandwidth to the internet for other
transfers and getting their responses faster at the same time.

And don't be reserved and afraid of trying new things, at least
in such area as common immaterial technology tricks ;)

HTH,
//Jim Klimov