Archiv:2009/IT/Konzepte/Serverstruktur/Konzept 2009

Aus Piratenwiki Mirror
Zur Navigation springen Zur Suche springen

Bitte Diskussions-Seite beachten.

Grundsätzliche Überlegungen

  • Welche Zielverfügbarkeit will man erreichen? 99.5% kriegt man noch einigermaßen hin, jeder Fitzel darüber wird gleich richtig richtig richtig kostspielig.
  • Will man HA-Cluster?
  • Will man Loadbalancing?
    • IP-Loadbalancer
    • Application-Level-Loadbalancer
  • Will man SSL? (Und wo soll es terminieren? Apache oder Loadbalancer?)
  • Will man Hardwarewartungsverträge abschließen? (Spielt auch bei der möglichen Verfügbarkeit eine Rolle, ob ich das Ersatzteil in max. 4h kriege oder "irgendwann".)
  • Performance: Dauerbetrieb vs. Lastspitzen (Wahlabend etc.)

Physikalische Server

  • 2x OVH MG-09 BestOf
    • 2x Intel Xeon (Core) Harpertown E5405
      • 4 Kerne
      • 2,00 GHz
      • FSB 1333
      • 80W TDP
      • 12MB L2 Cache
    • 16 GB DDR2 (non-ECC)
      • 4x 2GB Kingston DDR2-667
      • 2x 4GB Kingston DDR2-667
    • 2x 750 GB SATA HDD: Hitachi HDS72107 GK8O PQ
    • Supermicro X7DCA-L

Nachfragen: sind die Platten als HotSwap ausgelegt? Üblicherweise nicht, nur gegen Aufpreis. Dann bedeutet Ausfall einer Platte eine (allerding halbwegs planbare) Zwangspause.

Merker: Das SoftRAID muss entsprechend überwacht werden, damit der Ausfall einer Platte bemerkt wird und eine Wartungszeit eingeplant werden kann, bevor auch die zweite die Hufe reißt.

Virtuelle Server

  • ProxMox (virtuozzo, kvm)
  • (vserver)
  • (Solaris (mit Zonen)) - solaris ist interessant, aber wieviele kennen sich damit RICHTIG gut aus?

Storage

  • 500-600 GB RAID1 pro Server, gesynct mit DRBD und Heartbeat
    • Active-Passive-Variante: sicher, erprobt
    • Active-Active-Variante: neu, evtl. performanter
  • Darauf ein LVM, um den Platz dynamisch verteilen zu können.
  • Stellt gemeinsam genutzte Dateien zur Verfügung
  • Stellt Netboot-Images für Application-Server zur Verfügung
  • Stellt Netboot-Images für Cache-Server zur Verfügung
  • Stellt FAI-Install-Server zur Verfügung
  • Stellt Konfigurations-Files im SVN zur Verfügung
  • evtl. Home-Directories der Admins hier, sowie NIS bzw. LDAP zum Admin / User-Management für die Shells

Datenbank

Application

  • Kleine Partition oder Netzwerk-Boot
  • Holt sich die Daten via NFS vom Storage-Server
  • Installtion / Update der Config via FAI
  • Überlegung: Ein Application-Server für alle Services (Wiki, Forum, Web, Drupal, Wordpress, ...) oder getrennte Services
    • gemeinsam: Bessere Ausnutzung der Systemressourcen
    • gemeinsam: Beim Skalieren auf Physikalische Hardware kann man auf Virtualisierung verzichten
    • getrennt: Bessere Trennung der administrativen Zuständigkeit
    • getrennt: Bessere Abschirmung der Services voneinander
    • getrennt: Umzug einzelner Dienste Zwecks Loadbalancing zwischen den BareMetals ist mit VMs einfacher

Caching

  • Kleine Partition oder Netzwerk-Boot
  • Holt sich die Daten via NFS vom Storage-Server
  • Installation / Update der Config via FAI

Mail

  • Postfix mit DB-Mail und die normale DB mitbenutzen
  • Postfix mit DB-Mail und eine eigene DB verwenden
  • Postfix mit Dovecot auf dem Storage-Server
  • Postfix mit Dovecot auf eigenem Storage

Logging / Monitoring

  • sämtliche Log-Files von den Caching-Servern
  • Error-Logs vom Apachen?
  • Syslog von allen Kisten
  • Monitoring von System-Kennzahlen (load, free space, mem, #prozesse)
  • Monitoring von Dienst-Kennzahlen (requests, request-dauer)
  • Für's Logging von System- und Dienst-Kennzahlen Munin oder Cacti oder OpenNMS oder ...

Datennetzverbindungen

  • Öffentliche Interfaces für den Physikalischen Server
  • Öffentliche Interfaces für die Squid-Server (Load-Balancing-IP)
  • Open-VPN zwischen allen Maschinen als Private-Network zum Daten-Austausch
    • Mirror der Platten (Storage Server)
    • SQL-Server-Traffic (Replikation)
    • NFS-Traffic (Storage Server <-> (App-Server, Cache-Server))
  • /30er private Netze auf einem Server
    • HTTP-Traffic (App-Server <-> Cache-Server)
    • SQL-Traffic (DB-Server <-> App-Server)

Dienste

DNS

  • Primary oder Secondary Nameserver für alle Piratendomains

Datenbank

  • MySQL mit Master / Slave Replikation
  • Ein MySQL-Server für alles
  • Postgres ist zwar bessere Datenbank, aber wird von zu wenig Webanwendungen unterstützt

Mail

  • Mass Virtual Domain Mail Hosting
  • POP, POPs, IMAP, IMAPs-Zugriff
  • Webfrontend
  • Spamassassin
  • Sieve-Scripts
  • Mailinglisten
    • Mailman
    • Sympa

Application

Folgende Web-Apps wurden angefragt

  • Drupal
  • Wordpress
  • phpBB
  • MediaWiki
  • Groupware
    • openXchange (Skaliert sehr gut)
      • Wird in NRW eingesetzt, sehr gut integrierbar. mbraun als Ansprechpartner. Die Firma hinter dem Projekt ist der PP sehr wohlgesonnen bzgl. Lizenzsponsoring.
    • eGroupware (Haben einige im Einsatz, skaliert aber nicht gut)
      • Ralf Becker (Maintainer eGW) fährt bei Stylite eine eGW-Instanz mit zeitweise ca. 1000 concurrent Usern. Er würde uns mit Rat und Tat zur Zeite stehen. Wir bekommen von ihm eine unbeschränkte EPL-Lizenz mit vollem Support.
  • CiviCRM (Presse, Mitgliederverwaltung)
  • OTRS (Ticket-System)
  • (Bug-Tracker)? => pirateforge.org

Es müssten/sollten folgende Software paketiert werden:

  • Drupal (Multi-Site)
  • Wordpress (Multi-Site)
  • MediaWiki (Multi-Site)

Drupal für Master-Slave-Replikation patchen

Siehe [1]: Ändere Datei includes/database.mysql-common.inc: 

 function db_query($query) {
   $args = func_get_args();
   array_shift($args);
   $query = db_prefix_tables($query);
   if (isset($args[0]) and is_array($args[0])) { // 'All arguments in one array' syntax
     $args = $args[0];
   }
   _db_query_callback($args, TRUE);
   $query = preg_replace_callback(DB_QUERY_REGEXP, '_db_query_callback', $query);
 
   // Added on 5/21/2009 by apersaud
   // Integrating multiple read/write databases
   if (stripos($query, "select") === 0) {
     $commits = array('alter', 'insert', 'update', 'delete', 'flush', 'lock', 'create');
     $is_commit = false;
     foreach($commits as $type) {
       if (strpos(strtolower($query), $type)) {
         $is_commit = true;
       }
     }
     if ($is_commit) {
       db_set_active('default');
     } else {
       db_set_active('readonly');
     }
   } else {
     db_set_active('default');
   }
   return _db_query($query);
 }

Drupal für Squid optimieren

Siehe [2]:

Diverse settings anpassen. Nach Verifikation bitte dokumentieren.

PHP-Optimieren

  • Memcache sollte mit drauf
  • Vergleich verschiedener freier PHP-Optimizer: [3]
  • Vergleich Zend-Optimizer mit freien PHP-Optimizern: [4]

Jabber

  • OpenFire
    • (+) Bisherige Installation läuft damit
    • (+) Connection Manager zum ConnectionOffloading
    • (-) nicht Clusteringfähig (nur mit dem CommercialPlugin - mittlerweile abandoned)
    • (-) Speicherfresser solange alle User in einer Gruppe sind
    • (-) Probleme mit DNS-Caching von Dialup-IPs
  • eJabberd
    • (+) Clustering fähig
    • (+) vhost-fähig
    • (-) Erfahrung in Config und Betrieb nicht vorhanden
    • (-) keine bekannten Installationen in unserem Umfang
  • jabberd2
    • (+) mehrere große Installationen existent
    • (-) Erfahrung in Config und Betrieb nicht vorhanden

Authentifizierung

  • Piraten-ID für Single-Sign-On-Lösungen für E-Mail-Konten, Wiki, Forum, Groupware, openID-Anbindung, ...
Abgerufen von „https://wikimirror.piraten.tools/wiki/index.php?title=Archiv:2009/IT/Konzepte/Serverstruktur/Konzept_2009&oldid=55541209“