OpenSim Hosting

Het implementatieproces van een OpenSimulator server kan voor een organisatie behoorlijk complex worden. Er zijn een groot aantal factoren die van invloed zijn op de schaalbaarheid, de kosten en de snelheid waarmee een OpenSimulator omgeving in gebruik kan worden genomen. Het gaat dan om factoren zoals:


 * Beoogde toepassing en doelgroep. Welk doel heeft de organisatie voor ogen? Is dit realistisch? Kan dit op korte termijn uitgevoerd worden? Welke aanpassingen moeten gemaakt worden, moeten we zelf aan ontwikkeling gaan doen om onze doelen te bereiken, hoe verkleinen we de implementatietijd?, etc.


 * Intranet of Internet. Beveiliging, bandbreedte, terugkoppeling systeembeheer, alpha software


 * Server Type. Geheugen, CPU en Hardeschijf?


 * OS? Voor welk besturingssysteem kiest men?


 * ACL? maximum aantal objecten/scripts? Permissie checks? hypergrid? MRM? OSSL? welke talen mogen gecompiled worden? Welke toegangsrestricties worden gebruikt?


 * Hoeveelheid simultane gebruikers. Welke bandbreedte is nodig?


 * Schaalbaarheid. Grid of Standalone? Meerdere servers?


 * Aanvullende services. Usability? Voice? groepen? economy? web interface?


 * Backups en updates. Cron? Gebruikerbackups via webinterface? OAR/IAR?

De benodigdheden voor een OpenSimulator server kunnen voor iedere situatie anders zijn. Een bedrijf dat zich wil toeleggen op het aanbieden van OpenSimulator hosting of extern gebruik, zal wellicht andere keuzes maken met betrekking tot de infrastructuur dan een organisatie die een virtuele omgeving uitsluitend binnen het intranet gaat toepassen. Wanneer men sporadisch gebruik van de omgeving verwacht te maken, zal men wellicht ook lagere eisen stellen aan de server en aan de bandbreedte mogelijkheden. Iedere organisatie die een OpenSimulator omgeving wil implementeren, zal dit soort factoren in overweging moeten nemen, om de OpenSimulator omgeving goed tot zijn recht te laten komen. In deze wiki pagina worden een aantal van deze factoren beschreven, zodat u beter geinformeerd een keuze kunt maken met betrekking tot de toepassing van OpenSimulator binnen uw eigen organisatie.

Intranet of Internet
Beveiliging is het prioriteit van systeembeheer, dat tracht om het intranet waterdicht en operationeel te houden. Dataverlies en corruptie van systemen kunnen een grote kostenpost betekenen voor een organisatie. Dit is de reden waarom systeembeheerders over het algemeen niet blij zijn, om een alpha intranet server zoals OpenSimulator vanaf het internet toegankelijk te maken. OpenSimulator gebruikt port ranges van 8000-8006, en standaard een poort per regio(9000-9xxx). Ook is het een optie om code binnen OpenSimulator te laten compileren, wat beveiligingsrisico's met zich mee kan brengen. Na het zorgvuldig instellen van OpenSimulator en een firewall kan er niet echter niet veel meer misgaan. Dit proces kan echter wel tijdrovend zijn, omdat iedere stap in het ontwikkelingsproces in overleg gaat met systeembeheer. Over het algemeen zou men de volgende uitgangspunten kunnen aannemen, wanneer het gaat om de toepasing van OpenSimulator binnen de organisatie:


 * Gebruik een datacenter voor hosting, wanneer externe toegang vanaf het internet nodig is. Dit verkort de implementatietijd, en men heeft in een datacenter meer mogelijkheden om de bandbreedte en de servers te schalen.


 * Gebruik een intranet voor hosting, wanneer het gebruik van de omgeving zich vooral beperkt tot binnen de muren van de organisatie. De firewall kan dicht blijven, en uitsluitend werknemers binnen de organisatie hebben toegang.

DataCenter
Externe hosting kan op verschillende manieren. Een organisatie zou bijvoorbeeld kunnen besluiten om de virtuele omgeving onder te brengen bij een bestaande OpenSimulator provider. Ook kan men OpenSimulator services via een cloud-service zoals Amazon S3 aanbieden, waar men alleen betaald voor het werkelijk verbruikte internet-verkeer. Een andere oplossing is het huren van een VPS. Dit heeft het gemak van een eigen controleerbare server, maar heeft over het algemeen minder onderhoud nodig dan een dedicated server, is gemakkelijker te schalen en kost over het algemeen minder. De performance van een VPS is echter wel vaak minder dan een volledige dedicated server.

Virtualisatie is een logische stap wanneer men bijvoorbeeld hosting aan wil bieden. Op dit moment is geheugengebruik van de Simulators vaak de bottleneck bij implementatie. Uit metingen (Frisby, 2009) die bij OS-grid verricht zijn, en de aanvullende testresultaten van de drie Linux alfa-servers met Mono 2.4, blijkt het verbruik van geheugen (zie tabel 2.1) behoorlijk uit de hand te lopen. In de tabel wordt uitgegaan van een high-end regio, waarvan de specificaties ongeveer vergelijkbaar zijn met een volledig eiland bij Linden Lab.

Afhankelijk van de intensiteit van het gebruik van de omgeving, is men bij de keuze van een server door het relatief hoge geheugengebruik al gauw aangewezen op een high-end systeem, vanaf 4gb geheugen. Het franse bedrijf OVH heeft een dedicated serverpakket ('EG Max', Xeon Quad core, 8gb geheugen) dat hier goed op aansluit. De kosten bedragen ongeveer honderdveertig euro per maand. Gemiddeld kan men ongeveer vier regio's probleemloos draaien op een dergelijk systeem. De bandbreedte van dit pakket is 100mbps met 20.000GB dataverkeer inbegrepen per maand. Voor een gemiddelde gebruiker zal men ongeveer 200kbit bandbreedte moeten reserveren. Op een dergelijke server zou men daarmee, rekening houdend met de huidige geheugen bottleneck, zo'n 80 gebruikers tegelijkertijd kunnen bedienen. Naast OpenSimulator services voor simulators en grid-services, zijn er nog enkele services waar men rekening mee moet houden. Zo heeft men nog een Freeswitch VOIP-server nodig voor voice-ondersteuning, en Apache, MySQL en Python voor de web interface. In een grid-gebaseerde setup zou de web interface slechts op de centraal ingerichte grid-server hoeven te draaien.

== OS ==

Wanneer men besluit om een eigen dedicated server in te richten, is het volgende dilemma de te gebruiken besturingssoftware. Windows 2003/2008 gebruikt aanzienlijk minder geheugen voor .NET toepassingen dan Mono .NET voor Linux op dit moment. Daar staat tegenover dat Linux goed te optimaliseren is, geen licentiekosten heeft, veel mogelijkheden biedt om het beheer en onderhoud te automatiseren en dat Mono (inmiddels versie 2.4) steeds efficiënter met geheugengebruik omgaat. Uiteindelijk bepaalt de persoonlijke voorkeur van de betrokken IT'ers meestal de doorslag in de keuze voor de besturingssoftware.

Ongeacht de keuze voor het OS, kan de server met behulp van virtualisatie (bijvoorbeeld via Xen of Virtuoso) in vier of acht VPS-instanties worden opgesplitst, waardoor resources gelijkmatig tussen de verschillende simulators kunnen worden verdeeld.