Transcript

Sascha Daniels: Ich möchte Sie begrüßen zum Thema „Hochverfügbare Telefonanlagen mit Gemeinschaft und Linux Boardmitteln“. Mein Name ist Sascha Daniels. Ich bin Administrator, komme also aus der Praxis und bin bei der Wave Computersysteme GmbH beziehungsweise vielleicht besser bekannt unter Alternate Computerversand tätig. Ich möchte Sie im Folgenden ganz kurz eine Firmenvorstellung, also ganz kurz die Eigenwerbung, danach das Ziel von der ganzen Sache, das ist anhand von einem aktuellen Projekt. Die verwendete Software im Kurzen. Dann würde ich auf technische Details eingehen, auf Probleme und das daraus zu ziehende Fazit. Am Ende, denke ich, werden wahrscheinlich noch Fragen offen sein, da denke ich haben wir auch noch genügend Zeit dafür. Kurz zur Wave Computersysteme GmbH. Wurde 1990 gegründet. Reine Hardware Distribution. Kamen BtO Systeme dazu. Das Motto war schon immer „Alles Inhouse“. Das ist auch der Grund warum ich hier stehe. Weil wir irgendwann zur Tür gegangen sind und auch die Telefonanlage komplett in die Hand zu nehmen. Danach kam der Alternate Computerversand hinzu. Reines Endkundengeschäft. In der Zwischenzeit sind wir in Deutschland, Niederlande, Spanien, Österreich und Belgien verteten. Haben mehrere Callcenter und einen eigenen Webshop, der so aussieht. Falls den schon jemand gesehen hat. So, das war jetzt Eigenwerbung.

Hochverfügbare Telefonanlagen sind natürlich das Ziel. Das Ganze ist vor dem Hintergrund, in einer Filiale muss eine alte Siemens Hicom abgelöst werden, die hardwaretechnisch am Ende ist, kann nicht mehr erweitert werden. Support kriegt man dafür sowieso nicht mehr. Der Failover soll natürlich vollautomatisch passieren. Genauso der Failback, wenn der möglich ist. Kommen wir nachher noch dazu. Die Ausfallzeiten logischerweise minimiert werden. Und der Wartungsaufwand soll auch minimiert werden. Liegt unter anderem daran, dass dort vor Ort praktisch kein technisches Personal vorhanden ist. Muss alles per Fernwartung gemacht werden. Sollte also deshalb alles möglichst einfach auch gewählt sein. So, als zentrale Software kommt dabei, wie auch vorher in dem Vortrag zu MySQL und Hochverfügbarkeit, divergent Heartbeat, das was unter linux-ha.org zu finden ist, zum Tragen. Als auf der einen Seite natürlich Überwachung der Nodes und Steuerung des ganzen Clusters.

Als zweiter sehr wichtiger Punkt DRBD, kam vorher auch schon einmal dran. Ganz einfach gesagt „Raid 1 über Netzwerk“, was aber nur auf einer Node aktiv sein kann. Und das Ganze kennt zwei Replikationsmechanismen, einmal eine synchrone und einmal eine asynchrone. Wie das Ganze genau funktioniert, komme ich gleich noch dazu. Des Weiteren kommt MySQL Master-Master Replikation dazu. Hätte ich den Vortrag von vorher bereits gekannt, hätten wir ihn gleich zusammenlegen können, weil die Hälfte kommt hier genau wieder vor. Ich hoffe, also die Leute die da waren, nicht zu langweilen.

In unserem Fall ist es ein Asterisk 1.4.21, der zum Einsatz kommt. Aber ist im Prinzip beliebig. Gemeinschaft als Trunkinstallation oder als tgz. Der [unverständlich] kommt in dem Fall nicht so in Frage, weil es ist eine enorme Anpassung notwendig, würde ich deshalb also lieber eine stable Variante des tgz nehmen. So, die Hardware. Ich sage einfach zwei Server. Die wirkliche Ausstattung muss jeder selber wissen, je nach Callaufkommen, usw. Wieviel Speicher, wieviel CPU. Ist aber auch zweitrangig. Das einzige, was wirklich wichtig ist, sind die zwei Netzwerkkarten. [unverständlich] Dann verwende ich noch drei Festplatten in den Systemen. Jeweils ein Soft-Raid 1 mit Spare für das Systems und eines für das DRBD. Wie das genau zusammenspielt kommt auch noch. Es kommen keine PCI-Karten zum Einsatz, sondern ich verwende als Mediagateway eine Patton Smartnode, was auch diese ganze Failover-Prozedur in dem Fall wesentlich einfacher gestaltet. So, schematisch gesehen ist das ganze so aufgebaut über die zweite Netzwerkkarte hinten ist einfach mit dem Crosskabel verkabelt. Ist nur dazu da, erstens die DRBD-Daten zu synchronisieren und als Kommunikationskanal für Heartbeat. Auf den eigentlichen PINA Netzwerkkarten kommunizieren auch wiederum Heartbeat und fährt dementsprechend die virtuelle IP von der aktiven Node dann hoch. So, Heartbeat. Klar, gegenseitige Überwachung, aktive Übernahme der IP und Steuerung der DRBD. Zentrale Sachen. Steuerung der Dienste, ist auch klar. Im Failover-Fall kann man jetzt darüber streiten, ob man da eine Überwachungslösung wie Nagios oder wie auch immer VME einsetzt, verwendet. Aber am einfachsten ist, man lässt sich auch gleich von Heartbeat dementsprechend benachrichtigen, wenn mein Node inaktiv geworden ist. Was jetzt als ganz wichtiger Punkt dazukommt ist noch die Netzwerküberwachung über Ping Nodes. Das wird in sehr vielen Beschreibungen zu Heartbeat oft vergessen. Ist, ich zeige es nochmal anhand vom Schaubild, eigentlich relativ einfach. Angenommen, der Server hier ist aktiv, hat die virtuelle IP, und mir steigt dieser Switch aus. Dann erreichen sich beide Rechner gegenseitig nicht mehr, behaupten beide der andere sei tot. Der hier, Entschuldigung, ich habe es falsch gesagt. Der Switch ist aktiv und steigt mir aus, beide Rechner denken, der andere wäre tot, aber der aktive wird seine Ressourcen einfach nicht freigeben. Weil er eben auch denkt, der andere sei im Moment nicht mehr erreichbar. Deshalb sollte man auf jeden Fall auch eine Ping Node einführen. Normalerweise wird immer das Standard-Gateway genommen, in dem Fall könnte man auch die IP von der Smartnode nehmen. Und dann müssen eben beide Rechner zählen „Wieviele meiner Nodes erreiche ich denn noch?“ Und der, der mehr Nodes erreicht, der bekommt dann die aktive Ressource. Ansonsten, wie gesagt, passiert hier überhaupt nichts. So, Heartbeat. Wir kommen kurz zu DRBD, wie es tatsächlich technisch gesehen funktioniert. Es ist hier ein bisschen schlecht zu sehen, weil grau auf hellblau habe ich festgestellt, gestreift, funktioniert nicht so ganz. Das hier ist der inaktive Server. Zentral, hier drüben, das DRBD. Ist für das Betriebssystem und den Service der darüber liegt absolut transparent. Stellt einen Block Device dar. Also, darunter könnte man direkt Platten legen, man könnte ein Soft-Raid darunterlegen, könnten einen LVM darunterlegen. Also da ist, da sind dem Spieltrieb keine Grenzen gesetzt. Dazu kommuniziert man natürlich über TCP mit der jeweils inaktiven Node und synchronisiert normalerweise ständig die Daten auf dem zweiten. So, die Replikationsmechanismen. Es gibt erst einmal eine asynchrone Replikation. Die kennt zwei Varianten, also dieses A und B. Das ist in der demensprechende DRBD Config so angegeben. Das haben die sich einfach so ausgedacht.

Variante A: Schreibvorgang ist fertig, wenn der Block auf der Master Platte geschrieben wurde. Ja, hat so ein bisschen was von IDP, ja „fire and forget“. Man muss sich einfach darauf verlassen, es kommt auf der anderen Seite an. Ist eigentlich nur dafür gedacht, wenn die Replikation auf einen zweiten Server über extrem hohe Netzwerklatenz stattfinden soll. Weil ansonsten eben meine Applikation, die auf der aktiven Node darüber liegt ewig lange auf die Bestätigung wartet: „OK, Block wurde geschrieben“.

Das Ganze gibt’s noch in einer abgespeckten Variante. Da wird dem System zurückgemeldet: „Schreibvorgang war erfolgreich“, wenn die Daten zumindest im Cache des Slaves angekommen sind. Kann eine Variante sein, ich kann aber eben immer noch nicht garantieren, dass im Failover wirklich alles angekommen ist. In unserem Fall kommt die synchrone Replikation zum Einsatz. Schreibvorgang ist dann fertig, wenn wirklich der Block auf der inaktiven Node geschrieben wurde. Wodurch man einfach keine Transaktionen verlieren kann. Bei dieser Variante kann man sogar auf dem aktiven Server, könnte mir die Platte, die unter dem DRBD liegt, könnte mir aussteigen. Ich müsste keinen Failover machen auf den anderen Server, solange die Netzwerkverbindung steht und kann weiter darauf arbeiten. So, DRBD. Auf das DRBD ausgelagert wird in dem Fall normalerweise, also in erster Linie man von einer Gemeinschaftsinstallation ausgeht, würde man jetzt die /usr/src Gemeinschaft auslagern, um den Computeraufwand usw. zu verringern bzw. egal welche Node aktiv ist, um überall Ressourcen zu haben, habe ich das komplette /usr/src ausgelagert, um es einfacher zu haben. Danach wirklich alles was Asterisk angeht ebenfalls ausgelagert. Config Dateien, Init Scripte und eventuell weitere Scripte, da kommen wir nachher dazu. Das Ganze kann auf zwei Arten passieren, man kann entweder die Links alle komplett natürlich von Hand auf beiden Nodes dementsprechend generieren. Oder es gibt, wird mit DRBD mitgeliefert, ein Tool, das heißt DRBD Links. Da tragen Sie wirklich nur in der Config Datei ein „hierhin wird’s gemountet“ und danach kommen sämtliche Verzeichnisse oder eben auch Dateien, die dann dementsprechend auf dem DRBD liegen und sobald das DRBD jeweils gemountet wird, werden auch die Links gesetzt. Ja also, wenn man es von Hand macht, hat man tote Links, kann einem DRBD Links komplett abnehmen. Das es wirklich nur, auch die Links vorhanden sind, wenn der Server aktiv ist.

Publikum: Warum nicht das Ganze USL?

Sascha Daniels: Ja, da kriegen Sie mit anderen Diensten dann einfach Probleme. Also, die auf dem, auf dem passiven laufen sollen. Der kann sie ja überhaupt nicht mounten.

Publikum: OK.

Sascha Daniels: Ja, das ist, Sie haben überhaupt keinen Zugriff darauf, ja.

Publikum: Alles klar.

Sascha Daniels: Gut. MySQL Master-Master Replikation. Wurde schon angesprochen. Theoretisch ist das Schreiben immer auf beide Nodes möglich. Man hat dadurch natürlich keine Node-Balancing in irgendeiner Form, weil es ja auf dem anderen auch geschrieben werden muss. Aber auf jeden Fall kann man gleichzeitig auf beiden schreiben. In dem Fall hier Failback ohne Eingriff möglich. Das heißt, wenn mir der Server, der mir irgendwann kaputt gegangen ist, wenn er zumindest noch seine alten Daten hat, weiß, wo sich die Replikation befunden hat und ich natürlich auf dem anderen Server noch mein bin Logfile übrig habe. Wenn das natürlich nur auf zwei Tage eingestellt ist und der Server war jetzt leider fünf Tage down, dann habe ich leider natürlich verloren und muss auch die MySQL neu aufsetzen. Aber an sich, Server fährt hoch, synchronisiert sich wieder, genauso wie das DRBD, und ist wieder da. Deshalb habe ich auch hingeschrieben: „Failback ist nicht nötig“. Weil wenn die beiden Rechner die gleiche Hardwareausstattung haben, bleibt man einfach auf dem anderen und muss überhaupt nicht zurückswitchen. So, die klassischen Vorteile von einer Replikation. Man kann jederzeit auf dem inaktiven Server natürlich ein Backup machen. Kann auch alle Tabellen loggen, habe also dadurch auf jeden Fall einen Vorteil. Auswertungen könnte ich auf dem passiven Server machen, wenn sie dementsprechend intensiv sind, um den aktiven Betrieb nicht so in Mitleidenschaft zu ziehen. Und vom Rechtemanagement, um wirklich sicherzugehen, dass nicht jemand aus Versehen auf den falschen schreibt oder so, macht es halt wie immer Sinn, schreibend nur von localhost und lesend nach Bedarf zu setzen. So. Kommen wir zu, naja technische Probleme ist vielleicht ein bisschen falsch, zu ein paar Feinheiten von Heartbeat. Es gibt bei Heartbeat einen Wert, der nennt sich „initdead“. Das ist die Zeit, die Heartbeat hat, wenn es hochgefahren wird, um herauszufinden, ist die Gegenstelle da oder ist die Gegenstelle tot? Gerade beim Hochfahren, können das natürlich doch einige Sekunden sein, muss man dann wirklich an seine jeweilige Hardware anpassen, weil ansonsten fangen die schon beim Start an, munter hin- und herzuswitchen, wenn der eine eben zu langsam ist. Dann die tatsächliche deadtime. Sprich, ab wann darf die, kann die passive Node sagen „Gut, meine aktive Node ist tatsächlich nicht mehr vorhanden.“ Hängt schwer vom Netzwerk ab. Schwer vom Netzwerk ab. Ohne Spanning Tree hat sich das jetzt so durch Tests eigentlich eingependelt. 30 Sekunden, ja also 30 Sekunden downtime, dann kann man sagen „Gut, der ist wirklich weg.“ Was bei einem größeren Netzwerk mit Spanning Tree doch deutlich länger sein kann. Wer es also verwendet und eventuell sogar wirklich Spanning Tree und nicht Rapid Spanning Tree verwendet, weiß, wenn ein Switch aussteigt und der Tree sich neu aufbaut, kann es mal mehrere Minuten dauern, in denen es Aussetzer im Netzwerk gibt. Und da sollte natürlich jetzt hier Heartbeat nicht anfangen wild die Server hin- und herzuschalten. Da muss man also wirklich aufpassen, welche Zeit man da dann einstellt. Und eben nochmal, ganz wichtig, ohne Pingnodes ist das Ganze sinnlos. Darf man wirklich nicht vergessen. So, beim Asterisk gibt’s natürlich auch ein Problem. Das Switchen funktioniert zwar absolut schmerzfrei, allerdings gehen uns natürlich sämtliche Subscriptions der Hints verloren, wenn der Asterisk auf dem anderen neu startet. Ist klar. Muss man sich jetzt entscheiden: „Lasse ich das Ganze so, wie es ist, Hauptsache die Leute können telefonieren?“

Die nächste Variante ist natürlich alle Telefone booten. Da beim Ausfall des Servers wahrscheinlich sowieso alle Channels abgerissen sind, geht nicht anders, kann man das natürlich tun. Gemeinschaft bringt ja dementsprechende Scripte schon mit, mit denen es eigentlich recht einfach funktioniert. Kann man einfach im Init Script einbinden, alle Telefone booten und dann, alles ist wieder in Ordnung. Oder eben eine Alternative zu Hints verwenden. Da wird der Henning Holtschneider ja morgen noch was dazu sagen, dass es da auch Alternativen gibt, wodurch das eben nicht mehr notwendig ist. So, MySQL Master-Master Replikation. Ein ganz wichtiger Punkt sind auto increment Felder. Darf man nicht vergessen, es gibt zwei Werte bei MySQL für auto increment Felder. Das eine ist im Prinzip der Startwert und das andere ist der Intervall. Wenn ich auf zwei Server schreibe, und es eventuell tatsächlich so mache, dass ich sogar noch gleichzeitig darauf schreibe, kann es natürlich sein, ich erzeuge zweimal das gleiche auto increment Feld. Wird mir natürlich um die Ohren fliegen. Kann aber umgangen werden. Man kann, man muss auf beiden Servern den Intervall identisch setzen, aber den Standardwert, also sprich den Startwert, unterschiedlich. Dann funktioniert das Ganze auch. Da gibt‘s noch einen kleinen Bug im mysqldump, der die Gemeinschaftsmailinglisten mitliest. Der hat das auch schon mitgekriegt. Da geht’s aber nur um das Anlegen von Views. Der mysqldump baut leider das Anlegen von Views in mehrere Anweisungen um, was der Master gut interpretieren kann. Aber sobald es auf den Slave repliziert wird, funktioniert es nicht mehr und die Replikation bleibt stehen. Das heißt, einzige Variante, entweder zuerst beide Rechner, beide MySQL Server per Dump aufsetzen und dann erst replizieren. Oder den Dump dementsprechend anpassen. Das ist jetzt nur eine Zeile immer und dann funktioniert das auch wiederum. So, was kann man in diesem Szenario noch weiter [unverständlich]? Natürlich bietet es sich an, zusätzlich noch alle weiteren Dienste auch noch auf das DRBD zu legen. Kam jetzt bei uns in dem Fall nicht zum Tragen, weil DHCP Server läuft auf einem anderen Rechner. Samba haben wir dort nicht und Hylafax wird, im Moment zumindest, auch noch nicht verwendet. Aber theoretisch können Sie wirklich jeden Dienst, der nicht unbedingt notwendig ist, damit der passive Server läuft, auch aufs DRBD legen und haben ihn damit vollkommen redundant. Es gibt noch ein paar sehr schöne Ansätze bezüglich Backup. Ich habe ja vorhin schon gesagt, unter dem DRBD kann auch durchaus ein LVM liegen. Kann man in dem Fall dazu nutzen, um auf dem passiven Rechner einen LVM Snapshot zu erstellen. Von definierten Zeitpunkten. Und könnte dann dort sich auch sämtliche Dateien dementsprechend wegsichern, ohne auf irgendwelche Logs oder sowas Rücksicht zu nehmen. Gibt’s also auch noch die Möglichkeit. Wenn jemand für Statistiken oder sonst was extrem viele Lesezugriffe auf die Datenbank braucht, kann man natürlich noch beliebige MySQL Slaves an die beiden Master hinten dranhängen. Ja, gut, wenn es eben gebraucht wird. So, Fazit daraus. Es ist wirklich eine Ausfallzeit von unter einer Minute, ist machbar im Normalfall. Automatisierung wurde dementsprechend maximiert.

Kommt jetzt natürlich noch die Frage: „Wieviel Redundanz braucht man wirklich?“ Kommen wir gleich wieder zur Stromversorgung. Gut, ich habe zwei Server, die wahrscheinlich, hoffentlich an einer USV hängen. Brauche ich noch redundante Netzteile? Muss man dementsprechend natürlich selber entscheiden. Beim Netzwerk sind wir halt gleich wieder bei einem sehr hohen Kostenpunkt. Wenn ich sage, ich werde, verlege jeden Weg redundant, muß man eben alles dementsprechend selber entscheiden. Genau das gleiche ist das mit dem „Ich habe das DRBD über Raid 1 gelegt, macht das Sinn?“ Ich würde sagen eindeutig ja, weil so geschätzt sind 80% der Serverausfälle plattenbedingt, bewegte Teile. Dann habe ich lieber zwei oder drei Platten drin. Ist kein hoher Kostenfaktor, da lohnt sich es meiner Ansicht nach auf jeden Fall dann auch mehr anzustecken. Mediagateway, ist in dem Fall genauso wie das Crosskabel natürlich ein Single Point of Failure. Muss man sich auch überlegen. Wie weit vertraut man seinem, wie auch immer gearteten, Mediagateway. Kauft man sich auch wiederum zwei. Muss man natürlich da auch dementsprechend überlegen, wie man das wiederum anbindet. Ja, muss erst mal jeder für sich selber entscheiden. Es wurde ja auch im vorherigen Vortrag noch angesprochen, man kann die MySQL auch auf das DRBD legen. Das ist theoretisch richtig. Würde ich aus dem Grund nicht machen: Die ganzen Vorteile, wie ich kann die MySQL dementsprechend sichern im laufenden Betrieb auf der inaktiven Node, gehen mir dadurch verloren. Und natürlich ist die Startzeit von der MySQL, vor allem wenn man sich vorstellt, gut, ein Server crasht wirklich und er fängt überhaupt erstmal an bei InnoDB sein Log wieder abzuarbeiten. Dann sind wir bei einer Ausfallzeit, die ist höher als eine Minute. Von daher würde ich auf jeden Fall empfehlen, die MySQL immer auf beiden Rechnern laufen zu lassen. So, ich habe mich an die 30 Minuten gut gehalten. Ich habe auch gestern noch sehr viel gekürzt und wäre jetzt auch für irgendwelche Fragen offen.

Publikum: Was überwachen Sie mit Linux HA? Also, was für Tests lassen Sie laufen? Auch Asterisk-spezifische Tests, also…

Sascha Daniels: Nein, weil die Asterisk, ob der Asterisk läuft, ja oder nein, wird in dem Fall über Nagios dementsprechend überwacht und wird dann über einen Eventhandler, vom Nagios würde der Asterisk gestartet werden. Also da denke ich, wenn mir, wenn nur der Dienst an sich tatsächlich stirbt, ist es für mich noch kein Grund, Failover vom ganzen System zu machen. Und da würde ich dann Nagios oder jetzt in der aktuellen iX waren auch noch ein paar andere Projekte angesprochen. Irgendwas, was einen Eventhandler, was Eventhandler hat, würde ich da eher vorschlagen. Ich sehe, da ist irgendwas unter dem Licht.

Publikum: [unverständlich] Ich habe es noch nicht verstanden. Es ist ja jetzt ein active-passive System, oder?

Sascha Daniels: Genau.

Publikum: [unverständlich] Gibt es das auch als active-active Variante?

Sascha Daniels: DRBD wie gesagt kann theoretisch, mit dem dementsprechenden Filesystem darüber, kann man das active-active schalten. Wird aber mit relativer Sicherheit spätestens bei den Logdateien mit den Logs nicht mehr funktionieren. Also, weil ich, weil eben beide schreibend darauf zugreifen würden. Also, eine reine active-active Sache, ich habe die Doku dazu auch noch nicht gelesen, aber Stefan hat ja selber dazu gesagt, gibt’s auch noch nicht so wirklich. Gemeinschaft bietet ja die Möglichkeit, das Ganze so zu schalten, dass im Failover Fall eine andere Node übernimmt. Ist hier aber in dem Fall einfach nur als Sicherheit gegen Hardwareausfall. Keine weitere aktive Node. Keine weiteren Fragen? Gut, in dem Fall wünsche ich noch angenehme anderthalb Tage.

[Applaus]