Het gebruik van Linux als core systeem bij een satelliet-internet provider

Het gebruik van Linux als core systeem bij een satelliet-internet provider Geerten Schram Samenvatting Dit artikel gaat over het gebruik van Linux bij een satelliet internet provider.. De Provider biedt twee-richting internet toegang over een satelliet link voor zakelijke gebruik. Linux is in deze case ingezet op twee vlakken. Ten eerste in een router die door de Provider bij elke klant geplaats wordt. Ten tweede als standaard OS in het Internet Data Centre (IDC). Er zal worden ingegaan op de specifieke eisen die er gesteld werden aan beide toepassingen. Tevens wordt dieper ingegaan op de rol die LDAP heeft gespeeld als centrale directory server voor de configuratie van de routers en het mailsysteem.

Inleiding Dit artikel gaat over het gebruik van Linux in het kader van een opdracht die Linvision als onderaannemer van HP heeft uitgevoerd voor een nederlandse start-up die twee-richting internet toegang via satelliet aanbiedt. Hierbij heeft HP zorggedragen voor het ontwerp en de inrichting van het IDC/NOC en Linvision heeft het ontwerp en implementatie van de Zbox en de LDAP server en alle processen die de LDAP gebruiken verzorgd. De opdracht beperkte zich tot het ontwerpen van het IP gedeelte. Dat betekent van het ontwerp van een access point bij de klant, de Zbox, tot aan het data-center. Het satelliet gedeelte is ontworpen door een combinatie van twee Belgische bedrijven: Newtec en Alcatel. Figuur 1 geeft een overzicht tot welk gedeelte onze opdracht zich beperkte.

LAN (klant)

Satelliet HUB

IDU HostA

Newtec / Alcatel

IDC/NOC

Zbox

HostB

HP / Linvision Legenda: IDC: Internet Data Center

Internet

Figuur 1. Scheiding van de werkzaamheden.

NOC: Network Operation Center

IDU:

Indoor Unit decoder) (satelliet decoder)

In paragraaf Eisen gesteld aan het systeemwordt ingegaan op de specifieke eisen die een satelliet verbinding opleggen aan de componenten en aan de eisen die de klant aan het systeem gesteld heeft. paragraaf Het ontwerp geeft het ontwerp van zowel de afzonderlijke onderdelen als van het LDAP systeem dat de verbinding vormt tussen het IDC en de Zbox.

Eisen gesteld aan het systeem Zoals gezegd richt de Provider zich op de zakelijke markt en in het bijzonder het midden- en kleinbedrijf (tot 100 aangesloten systemen). Naast internet toegang biedt de Provider e-mail en webhosting aan in hun abonnement. De geplande groei is 1.500 klanten in het eerste jaar (2002), 15.000 in het tweede en vervolgens doorgroeien tot 50.000 klanten in 2004. Behalve de "normale" eisen die gesteld worden aan de infrastructuur van een internet provider gelden er door het gebruik van satelliet technologie nog een aantal aanvullende eisen. De normale eisen die gesteld werden waren: •

hoge beschikbaarheid

•

uitstekende beheersbaarheid

•

veiligheid

•

goede schaalbaarheid

De aanvullende eisen zijn een gevolg van het gebruik van een satellietlink. Door de grote afstand die het satelliet signaal aflegt, tweemaal de afstand tot een geostationaire baan (2 x 36.000 km), is het signaal voor een enkele reis al 240 ms onderweg. Dat betekent een round-trip tijd zonder ook maar enige netwerk latency van minimaal het dubbele hiervan (480 ms). Naast de hoge latency heeft een satelliet verbinding ook een gemiddeld verlies van één procent van de verzonden data. Dit heeft een aantal vervelende effecten op de netwerkperformance van met name TCP verkeer. Een TCP sessie bouwt de transmissie snelheid geleidelijk op door eerst één pakket te zenden en als dat pakket goed over gekomen is er twee te sturen, enzovoort. Meteen wordt duidelijk dat door de lange tijd die het kost om een bevestiging te krijgen dit proces langer duurt en zelfs tegen een maximum aanloopt (het ingebouwde mechanisme voor netwerkcongestie). Het hoge verlies verergert dit vanwege het feit dat het protocol "terugschakelt" naar minder pakketten per tijdseenheid na een een mislukte transmissie. Het theoretische maximum ligt hierdoor op ongeveer 128 kbps (bij een window size van 8 KB). De klant stond erop dat er een oplossing voor dit probleem gevonden moest worden om voldoende bandbreedte aan haar klanten aan te kunnen bieden.

Eisen aan de Zbox Bovenstaand vertaalt zich in de volgende eisen voor de Zbox die bij elke klant geïnstalleerd wordt. Beschikbaarheid De dienst moest een hoge beschikbaarheid krijgen. Bij eventuele hardware storingen was het voldoende als de Zbox vervangen kon worden door een willekeurige reserve Zbox. Beheersbaarheid De Zbox moest volledig remote configureerbaar zijn en gecontroleerd kunnen worden. Veiligheid Eisen op het gebied van veiligheid waren dat de Zbox een strikte firewall moest krijgen om het LAN van de klant af te schermen van het internet. Bij alle software componenten die gebruikt zouden worden was veiligheid een belangrijk criterium.

Schaalbaarheid Om zoveel mogelijk klanten via de satelliet link te kunnen bedienen moet er zoveel mogelijk data gecached worden: •

http

•

dns

•

lokaal e-mail verkeer

Bandbreedte Een oplossing moest gevonden worden voor de beperkingen die de satelliet link stelt aan TCP. De maximale bandbreedte van de satelliet link dient benaderd te kunnen worden. Gebruikersgemak De Zbox moest zo makkelijk mogelijk in gebruik genomen kunnen worden. Er is voorzien in een installatieprocedure die uitgevoerd wordt door geselecteerde montagebedrijven. Veel tijd is nodig voor het monteren en uitrichten van de satellietschotel. De montagemonteurs zijn geen netwerkspecialisten. Een ’plug-and-play’ installatie was zeer gewenst.

Eisen aan het datacenter Naast de reeds genoemde eisen aangaande hoge beschikbaarheid, beheersbaarheid, schaalbaarheid en veiligheid golden nog een aantal aanvullende eisen: IP Routing Het IDC is de standaard gateway voor elke Zbox. webhosting Elke klant krijgt eenvoudige webhosting aangeboden horend bij zijn abonnement e-mail In het IDC moest een centrale e-mailserver (POP) komen voor alle klanten DNS services Om controle te kunnen houden over voornamelijk het e-mailverkeer wilde de Provider de authorative DNS verzorgen voor de domeinen van al haar klanten.

Het ontwerp Dit hoofdstuk beschrijft welke oplossingen gekozen zijn om aan de wensen van de klant te kunnen voldoen. Eerst zullen de punten aangestipt worden die dit project uniek maken en die om een creatieve oplossing vroegen. Op één van deze punten ga ik later dieper in, na kort aangegeven te hebben hoe aan de overige eisen is voldaan.

De unieke eisen Na bestudering van het programma van eisen sprongen er twee zaken uit: 1. De beperkingen van TCP voor gebruik over een satellietlink. Nadere studie leerde dat TCP in het geheel niet geschikt is als protocol over een satellietlink. Op de markt bestaan producten speciaal voor gebruik over een satellietlink. Gekozen is voor Mentat’s SkyX.1

SkyX is een vervanger voor TCP. Het normale TCP verkeer wordt zowel op de Zbox als in het IDC afgevangen en geconverteerd naar SkyX. In het IDC wordt daar een SkyX router van Mentat zelf voor gebruikt. Op de Zbox is een OEM versie van de software ingebouwd. Het TCP verkeer van de klant wordt op de Zbox afgevangen door een conversie proces dat de staat van alle TCP sessies controleert. Er vindt zowel op de Zbox als in het IDC een protocol conversie plaats. Het is niet zo dat TCP getunneld wordt door bijvoorbeeld UDP. TCP sessiegegevens gaan dus niet over de link maar worden op de Zbox (voor het LAN) en in het IDC (voor verkeer vanaf het internet) getermineerd. De processen die het TCP verkeer afvangen kunnen op basis van de overgezonden data via het SkyX protocol bepalen of ze bevestigingen (ACK) kunnen sturen naar de corresponderende host. 2. De beperking van e-mail verkeer over de satellietlink. Om het interne e-mailverkeer van een klant niet over de link te laten gaan én in het IDC ongewenste e-mail af te vangen betekent dat e-mail informatie zowel in het IDC als op de Zbox beschikbaar te zijn. De oplossing die hiervoor gebouwd is wordt later in detail besproken.

De gekozen oplossingen voor de overige eisen Kort wordt voor het IDC en de Zbox aangegeven hoe de overige eisen en wensen vertaald zijn. Oplossingen voor het IDC Het IDC is omwille van veiligheid en schaalbaarheid opgedeeld in verschillende zones. Al deze zones hebben een redundante gigabit backbone. De scheiding tussen de zones bestaat uit verscheidene firewalls. Er is een Internet zone, een zone voor de extern benaderbare diensten (e-mail en DNS), een webhosting zone, een zone voor interne diensten (e-mail, DNS en LDAP) en een zone waar vanuit alle componenten gecontroleerd en bestuurd worden. Als netwerk monitor/beheersysteem is gekozen voor HP’s OpenView 2. Dit voor zowel alle apparatuur in het IDC als voor alle Zbox-en. Voor de webhosting wordt gebruik gemaakt van Apache. De klantgegevens worden gehaald uit een centrale LDAP directory. Op deze LDAP directory wordt later dieper ingegaan. Ook de DNS krijgt hieruit al zijn dynamische domeingegevens.

De oplossingen voor de Zbox De Zbox is in wezen een uitgeklede PC. Als OS is gekozen voor Linux, voornamelijk vanwege de goede remote beheer mogelijkheden en de beschikbaarheid van de SkyX software. Op de Zbox worden de standaard firewall mogelijkheden van Linux gebruikt voor de beveiliging van het netwerk van de klant. Daarnaast draait er een webcache (Squid) 3 een caching DNS service, een interne DNS server (reversed DNS voor het interne LAN), een (optionele) DHCP server, een POP server voor elke gebruiker op het interne LAN en een SMTP server. Om de Zbox zo makkelijk mogelijk in gebruik te maken worden alle initiële configuratie gegevens tijdens booten opgehaald uit het IDC. De Zbox bepaalt welke gegevens hij moet ophalen uit het IDC aan de hand van een unieke identifier die van de IDU wordt verkregen. Dit mechanisme maakt het mogelijk dat Zbox-en met elkaar uitwisselbaar zijn.

De spil in het web: LDAP Om niet onnodig (dure) bandbreedte te verbruiken was er de wens om lokaal (voor de klant) e-mailverkeer niet over de satellietlink te sturen. Deze eis hield impliciet in dat er een volledige e-mailserver op de Zbox moest komen. Tevens wilde men alleen e-mail voor bestaande emailadressen naar de Zbox doorlaten. Om aan deze twee eisen te kunnen voldoen moet dus

zowel het IDC als de Zbox gebruikersinformatie hebben. Om consistentie in deze gebruikersgegevens te kunnen waarborgen is gekozen om in het IDC álle gebruikersgegevens vast te leggen. Naar elke Zbox worden alleen de relevante gegevens gerepliceerd. Dit gebeurt door middel van een PUSH replicatie. Nadat er besloten was om voor de mail een centrale opslag van gegevens te hebben, is gekeken of er meer gegevens hierin opgenomen kon worden. Besloten is om álle configuratie gegevens die de ene Zbox onderscheiden van een andere in deze centrale opslag op te nemen. Deze centrale opslag bevat nu ook alle klantgegevens nodig om de e-mail, DNS en webhosting in het IDC te kunnen configureren. Als centrale gegevens opslag is gekozen voor een LDAP directory. LDAP staat voor Lightweight Directory Access Protocol. Informatie wordt opgeslagen in een directory-achtige structuur. In dit geval is er voor elke Zbox een takje waarin alle voor die Zbox relevante informatie is opgeslagen. Automatische configuratie Zowel in het IDC als op de Zbox worden diensten geconfigureerd met de centraal opgeslagen gegevens. Uitgelegd wordt hoe dat in zijn werk gaat In het IDC In het IDC worden de e-mailservers, de DNS servers en de webservers geconfigureerd met gegevens uit de LDAP. Hoewel de gekozen software rechtstreeks met LDAP kan communiceren hebben we hier voor e-mail en DNS voor een andere aanpak gekozen. De topologie van het netwerk en de toegangrechten tot de gegevens hebben geleid tot een directorystructuur die directe toegang van de e-mailserver niet wenselijk maakt. In plaats daarvan wordt nu een aantal maal per uur alle voor e-mail en DNS relevante gegevens uit LDAP gehaald en opgeslagen in aparte databases. Dit had als bijkomend voordeel dat het mailsysteem in het IDC niet meer afhankelijk is van de beschikbaarheid van de LDAP server. De toegangsgegevens tot de webservers door middel van FTP komt wel direct uit de LDAP database

Op de Zbox De Zbox kent twee verschillende manieren waarop de gegevens uit de centrale LDAP in zijn lokale LDAP komt. Tijdens booten wordt de complete tak van de desbetreffende Zbox opgehaald vanuit het IDC. De opstartscripts zijn zo opgezet dat ze de benodigde configuratiegegevensgegevens uit de lokale LDAP server halen. Latere wijzigingen van gegevens in de centrale LDAP server worden van de centrale server naar de lokale server gerepliceerd. De mailserver op de Zbox raadpleegt de lokale LDAP server rechtstreeks.

Beheer van de LDAP gegevens Om zowel het IDC te ontlasten als de klant controle te geven over zijn mailadressen kan de klant zelf e-mailadressen en POP boxen vanaf zijn LAN beheren. Tevens zijn er nog een aantal andere parameters in te stellen zoals het wel of niet gebruiken van de interne DHCP server en het IP nummer van de LAN interface. Deze gegevens worden rechtstreeks in de centrale LDAP server geschreven en vervolgens gepushed naar zijn Zbox.

De stroom van het e-mailverkeer Voorbeeld van lokale e-mail De weg die lokale e-mail aflegt is als volgt. Stel Jan ([email protected]) stuurt een mailtje naar zijn collega Piet ([email protected]). Op het interne LAN is als MX record voor klant.nl de lokale Zbox gedefinieerd. Het mailtje van Jan met als SMTP server de Zbox verlaat dus het LAN niet.

e-mail verstuurd vanaf het internet E-mail gestuurd van een willekeurige plek vanaf het internet naar Jan ([email protected]) komt eerst aan op de mailserver in het IDC aangezien de externe DNS in het IDC als MX-record voor klant.nl hiernaar verwijst. Deze e-mailserver zoekt nu in zijn gebruikersdatabase of [email protected] een geldig e-mailadres is. Zo ja dan wordt de e-mail doorgestuurd naar de Zbox. De SMTP server in het IDC haalt deze gegevens uit zijn configuratie. Het afleveren van de e-mail op de Zbox gebeurt dus niet op basis van MX records. Als het een niet bestaand e-mailadres is ([email protected]) dan wordt de mail geweigerd en krijgt de verzender een melding dat dit e-mailadres onbekend is. De mail wordt direct afgeleverd bij de Zbox door de mailserver in het IDC. In het IDC is dus geen opslag nodig voor mailboxen van individuele gebruikers. De capaciteit van de mailserver wordt alleen bepaald door zijn mogelijkheden om mail door te sturen en niet door de opslagcapaciteit in het IDC.

Conclusie Vanwege de eisen die de klant stelde ten aanzien van voorkomen van bandbreedte verspilling hebben we met behulp van LDAP een gedistribueerde mailomgeving gebouwd. De aanwezigheid van de centrale LDAP server maakte het tevens mogelijk om alle data die de ene Zbox onderscheidt van de andere hierin in op te slaan. De Zbox gebruikt deze gegevens om zich automatisch te configureren wat het beheer en de schaalbaarheid ten goede is gekomen.

Noten 1. http://www.mentat.com/ 2. http://www.openview.hp.com/ 3. http://www.squid-cache.org/