www.fridu.net

While major ISP like Orange, Vodafone, Telfonica, ... have a numbers of independent cabinet to compartmentalize their architecture, this is not an option for small non profit or SOHO organizations that in no way justify such complex architectures and/or neither can afford it.

This note describes "Fridu-in-Xen" virtual ISP architecture, it explains how to simulate a fully compartmentalize mini ISP (Internet Service Provider) running on a unique Linux box and hosted on a cheap remote site (OVH ) leveraging XEN, VPN and QoS. It is build in such a way that anyone with an acceptable level of network and Linux knowledge should be able to replicate the architecture on its own hardware in few hours, then if you like it you may start contributing to the improvement process.

I use this architecture in real for fridu.org to support a number of non profit organizations, obviously it still lack some nice feature like redundancy, load balancing, supervision, ..., it's not that we could not extend "Fridu-in-Xen" to support it, but I have neither the time neither requirements for it. Nevertheless, in its current version it already allows you to provide for a very reduce cost of administration every typical services we expect from a good service provider Portal, Messaging, Voice/IP, ...this with an acceptable level of quality of service including security, backup, QoS, ...

Disclaimer

Anything I wrote here was done outside of my professional work context and  none of my current/past employers/customers have participate or even be consulted for this work. Fridu is 100% part of my free time, and everything including hosting is funded on our pocket money and used to support non commercial friend organisations. While I think I have the technical background to design a smart architecture (cf:my profile). I nevertheless do not garanty that it will work for you, or even that you will agree with me. I still hope it may help some of you and I would be more than happy to incorporate improvement if ever you have some.

Introduction

For professional reason I was been lead architect for few major internet service providers in Europe, while obviously most of us do not requirer this level of architecture complexity, and without taking about majors GSM-operators and/or world wide contend providers that count users in tens or hundred of million, most of us will never have to deal with even a small million of users.

This being said, even if you support only few tens/hundred of users it is very nice to have a compartmentalized architecture, where you can start a new instance of Linux for a test server in few minutes and/or do a disaster recovery without sweating for hours.

Fridu-In-Xen architecture was design, with the same security constrains and administration concern than big ISPs, only replacing physical element with virtual equivalence. The fundamental requirement was to build an architecture that was as close as possible for the administrator of a traditional physical architecture. I still lack some features like fault tolerance or load balancing, we could obviously add it, and I have no doubt that the same paradigm would work, but within Fridu usage context I have not justification for such an effort.

When using Fridu-In-Xen type of architecture? obviously when ever you want :) This being said it was designed after few major crashes we had one box we used for hosting fridu in the past. Each crash generated best case one night of work and worse case a full weekend. We also had trouble to upgrade some services because of the interdependency of all applications running together in a shared cabinet and when ever we had to reboot after a security update it was a nightmare. Last but not least, because Fridu is 100% based on volunteer work, everyone tend to cook its own food before eating it. Unfortunately this lead in, far too many people with far too many access right, and when a problem raise you never know who made it.

Conclusion: if you want a small and simple architecture than allows you to:

• Add/Recreate an instance of Linux is less than 5mn
• Provide untrusted user with root access to their VM without sweating
• Keep a complete control of your infrastructure without dealing with the detail of each VM
• Have access to a simple administrative network, that makes transparent  the fact that you share a physical cabinet with others.
• Have control on QoS (Quality of service) at network, Ram, Disk level
• Handle smartly multiple external NAT IP addresses.
• ...

Then you should probably check Fridu-In-Xen. Alternatively your may want to check Fridu OpenVZ (here)

ISP typical architecture

Most serious Internet service providers are organized in zones, even if they may use different name like: clouds, classes, .... Each zone groups a couple of machines that share both a common level of security and a class of service. In order to guaranty high availability a zone must at least have two physical boxes, but depending on provided services and load a given zone may have ten or more physical/virtual boxes. Within a zone load is balanced, today load-balancing is mostly achieve by hardware intelligent switch/routers like Alteon, Cisco, ... all those modern hardware provide a very secure way of isolating port by VLAN and outside of some very paranoiac users l(bank, government, ...) most people will accept to share the same physical routers even for different security level. Administration is typically done through a completely independent network, that have a multi-legs firewall in order to make sure that even if a hacker take control over one zone, he cannot use the admin network to move from one zone to the other. Following graphic give a typical view of current major ISP architectures, and depending on the number of physical boxes could be extended from few thousand to few million users.

 Fridu Xen Architecture

As explained in the introduction, the goal of Fridu Xen architecture is to provide for minimal fraction of the cost the same level of administration and security facilities, we do have with a conventional ISP architecture. Nevertheless we have to accept some limits, especially hight availability will be reduce has we only have one physical box, obviously we could have two of them and use some software load balancing methods, but as today this is not part of Fridu-in-Xen reference model (may be later :)). Nevertheless looking at today hardware stability, associate to facilities offer by virtualization for backup, restore and relocation of virtual machines this architecture model attached to a good backup strategy and disaster recovery plan, should be more than enough for medium size operation, this especially for non profit organizations that what ever they need do not have funding for conventional ISP type of model.