Voraussetzungen und Erfahrungen aus Projekten

Transkript

1 Netzwerk für Cloud-Services (11.45 Uhr, Track 3) Voraussetzungen und Erfahrungen aus Projekten Gerardo Cicchetti, PH Networks AG Hans-Peter Racheter, Kulturzentrum Braui Manuel Fraefel, Studerus AG

2 Netzwerk für Cloud-Services Wichtig ist nicht, wie klein Sie sind Gerardo Cicchetti Hanspeter Racheter Manuel Fraefel

3 Agenda Die Schauspieler und Akteure Am Anfang war das Feuer... Doch bald begann es zu regnen Zum Regen gesellte sich der Wind Zusehens trocknete wieder alles Wo die Sonne scheint, fällt auch Schatten... Nobody is perfect

4 PH Networks AG 15 Mitarbeitern im IT- und Telekommunikationsbusiness Im laufenden Jahr feiern wir das zehnjährige erfolgreiche Bestehen Starke Partnerschaften u.a. mit Studerus, Swisscom, HP, Symantec, Citrix Focus Gesamtlösungen und deren Betrieb im Outsourcing Aktuelle Cloud-Apps: ERP, CRM, FIBU, EMS, BCON, SQL, HEX, MAV, BAK Spezialisierung Echtzeitüberwachung und Remote-Management

5 Am Anfang war das Feuer (Wunschliste) Vision: Vollständige und automatisierte Redundanz aller RZ-Komponenten WAN-Anbindung Switch-Konzept SAN-Systeme Host-Servern Backup-NAS (Co-Location) Kd-Erwartung: kalkulierbar, besser, schneller, immer, flexibel, sorglos Anbindung mit hoher Verfügbarkeit 99.98% mit/ohne Redundanz

6 Am Anfang war das Feuer (Entwurf) PHNAG Switch-Kaskadierung USG LAN USG LAN 1 2 SW01 GS SW02 GS SW03 GS VOIPSW GS PWR TITEL Switch Übersicht PFAD VisioDocument DATUM ERSTELLT VON ME ZEICHENBLATT 1 VON 1

7 Am Anfang war das Feuer (Studerus) USG-300 statt 200 (mehr WANs) Sync Host-Switches (via VRRP) neue iscsi-switches Dummy-Switches (für WAN-Redundanz)

8 Am Anfang war das Feuer (Verdrahtung) 1.Umsetzung Jan.2010 (mit Studerus-Techniker) 4x VM-Hosts 2x iscsi-san 2x Backup-NAS 2x iscsi-switches 2x Core-Switches 2x Client-Switches 2x WAN-Switches 2x 300er-USGs 2x 15Mbps WAN (WWZ) 2x 20Mbps WAN (Swisscom)

9 Dann begann es zu regnen (Problembereiche) Implementierung gemäss Theorie Redundanz zwischen Switches klappt nicht wunschgemäss Zusammenspiel mit redundante USGs macht Probleme Intensive Ursachenabklärungen Studerus <> ZyXEL Umstellung auf «manuelles» Cold-Standby bis zu Neuversuch Günstige NAS/SAN-Geräte (QNAP) weisen unbrauchbare Verfügbarkeit Kompatibilitäten VMware - QNAP ZyXEL mangelhaft

10 Zum Regen gesellte sich der Wind (Connectivity) Verfügbarkeit der Cable- und xdsl-anschlüsse ungenügend Verschiedene ISPs führten zu Summierung von kurzzeitigen Ausfällen Kundenreklamationen immer lauter, Geduld immer kleiner Echtzeit LAN-Monitoring auf SNMP-Basis provozierte USG-Crashes Lange Erstellungszeiten von dringend bestellten Glasanschlüsse Zunehmende Kd- und SaaS-Basis führte zu mehr SAN/NAS-Problemen Enorme Aufwendungen für dringende «Lebenserhaltungsmassnahmen» Ungeplante und teure Investitionen in professionelle SAN-Geräte Pikettdienst war gut ausgelastet

11 Zusehens trocknete wieder alles Glas per Mitte 2010 fertiggestellt (endlich) Neu LAN-i für IaaS + PaaS Neu IP-Plus für SaaS Neu HP-SAN statt QNAPs Neu Co-Location für Backup-NAS Cable+DSL als Fall-Back VDSL für Secondary-Services

12 Wo die Sonne scheint Chassis-Switch Anfangs 2011 (mit Studerus-Unterstützung) Neu redundanter Switch Neu vmotion ohne Grenzen (mit Layer3-Switch erschwert) kleinerer Gerätepark seither keine Aus- und/oder Zwischenfälle mehr

13 Da fällt auch Schatten Mangel: Blockierung von VLAN-Traffic untereinander ganz oder gar nicht Wunsch: weitere Reduktion von klassischen Switches Wunsch: RZ Co-Location Trend: grosse RZs von grossen Anbietern (Swisscom, Green usw) Trend: Mischform d.h. hybride Cloud-Services werden zu Gesamtlösung vernetzt Trend: Systemintegratoren werden sich zunehmend zu Cloud-Integratoren entwickeln

14 Kulturzentrum Braui by Hanspeter Racheter

15 Das «älteste» Cloud-Kind Ursprung über 10-jährig (damals als ASP-Dienst bekannt) Herausforderungen & Probleme: über 500 Events/Jahr per Excel = Mission Impossible fehlendes Reservierungssystem/CRM, keine Abrechnung hoher Administrations- und Organisationsaufwand Von der Vision zur Lösung: All-in-One Event-Management-System von Kontakt- Personal, Ausrüstungsverwaltung, Offerte, Auftrag, Abrechnung, CRM sowie Regieplanung inkl. Statistiken Ergebnis EMS/ERS by Hanspeter Racheter

16 Event- und Resourcenplanung leichtgemacht by Hanspeter Racheter

17 Ist wirklich alles Gold was glänzt? Glanzpunkte dynamische und rasche Anpassung überall und jederzeit zugänglich mandanten-/cloudfähig alle für einen, einer für alle (speziell bei Erweiterungen) Mietgebühr inkl. Full-Service/-Support keine Investitionen (ausser Initial-Setup) sorglos z.b. Datensicherung mit Langzeitarchivierung Schattenpunkte Klassische Probleme wie Anpassung an veränderte Office-Versionen Integration immer neuer Mobile-Device nicht ganz trivial by Hanspeter Racheter

18 Besten Dank für Ihre Aufmerksamkeit! Wichtig ist nicht, wie klein Sie sind sondern wie gross Sie werden wollen.

19 Physische Redundanz mit einzelnen Core Switch RSTP

20 Physische Redundanz mit einzelnen Core Switch Hardware Redundanz durch doppelte Auslegung aller kritischen Komponenten (Switch) Anschlüsse redundanter Geräte werden auf unterschiedlichen Switch terminiert um einen Geräte Ausfall zu kompensieren alle Netzwerkkomponenten sind mehrfachen verbunden um Geräteund Link-Ausfälle zu kompensieren Wartung oder Auswechseln von Komponenten im Netzwerk kann ohne Unterbruch des Betriebs durchgeführt werden für nicht redundant angeschlossene Komponenten kann ein Cold Standby Switch verwendet werden die Stromversorgung redundanter Komponenten sollte über unterschiedliche Phasen (USV) geführt werden es wird auch im Layer2-Betrieb ohne VLAN eine spezifische Konfiguration benötigt um von der Hardware-Redundanz zu profitieren (RSTP)

21 logische Redundanz mit VLAN und VRRP FW VLAN VRRP 3 Client VLAN RSTP VRRP 2 Client VLAN Server VLAN Server VLAN VRRP 1 iscsi VLAN

22 Physische Redundanz modularer Core Switch

23 Physische Redundanz modularer Core Switch Hardware Redundanz durch modulare Komponenten des Switch Anschlüsse redundanter Geräte werden auf unterschiedlichen I/O Modulen terminiert um einen I/O Modul Ausfall zu kompensieren lokaler I/O Modul Layer 2 Traffic wird durch die I/O Modul eigene Switching Fabric geleitet und benötigt nicht die Switching Fabrics in den beiden Management Modulen inter I/O Modul Layer2/Layer3 Traffic kann redundant von den unabhängigen Switching Fabrics in den beiden Management Modulen gehandhabt werden für nicht redundant angeschlossene Komponenten kann ein ausgefallenes I/O Modul im laufenden Betrieb ausgewechselt werden (Hotswap) die Stromversorgung wird über zwei Netzteile redundant geführt im Layer2 Betrieb ohne VLAN wird keine spezifische Konfiguration benötigt um von der Hardware Redundanz zu profitieren