Perrypedia:Wartung

Aus Perrypedia
Wechseln zu: Navigation, Suche
Google translator: Translate from German to English.
Google translator: Přeložte z němčiny do češtiny.
Google translator: Vertalen van Duits naar Nederlands.
Google translator: ドイツ語から日本語への翻訳
Google translator: Traduire de l'allemand vers le français.
Google translator: Traduzir do alemão para o português.

Um diese Seite übersichtlich zu gestalten, bitte

  • neue Beiträge/ Fragen oben und nach dieser Textbox einfügen.
  • jedem neuen Beitrag eine Überschrift geben (z.B: == Diskussionsthema ==).
  • mit zwei Bindestrichen und vier Tilden (--~~~~) unterschreiben.

Archivierte Beiträge

2011–2013 | 2014–2016 | 2017 ...


Einschränkung bei den Spezialseiten

Gestern vormittag hat jemand - eine IP-Adresse aus Frankreich - die Perrypedia ins Visier genommen, eventuell ein aggressiver Bot, könnte aber auch ein Hacker gewesen sein. Hat relativ wahllos versucht, Seiten abzurufen und manchmal auch zu editieren, was natürlich nicht klappt ohne Benutzerkonto. Normalerweise steckt der Server so etwas ganz gut weg. Ungefähr 10.31 Uhr hat diese IP die Seite "Spezialseiten" entdeckt und binnen Sekunden ein paar davon aufgerufen: Verwaiste Seiten, nicht kategorisierte Kategorien, Defekte Weiterleitungen usw., darunter ein paar lang laufende. Mehrere dieser schwergewichtigen Abfragen gleichzeitig, das ist Schwerstarbeit für die Datenbank und kann dazu führen, dass normale Abfragen auf der Strecke bleiben.
Damit sich das nicht wiederholt, habe ich den Zugriff auf mehrere Spezialseiten eingeschränkt auf angemeldete Benutzer. Nicht angemeldete werden ausgeschlossen von lang laufenden Spezialseiten, von Spezialseiten mit allen oder sehr vielen Ergebnisseiten und vor allem auch von der Spezialseite mit der Übersicht aller Spezialseiten. --Klenzy (Diskussion) 19:03, 7. Sep. 2019 (CEST)

Serveraustausch

Der unfreiwillige Serveraustausch ist abgeschlossen, die Perrypedia läuft wieder. Diesmal hat unser Provider Strato sehr schnell reagiert, dafür habe ich für die Wiederherstellung deutlich länger gebraucht. Mir sind einige Fehler unterlaufen, von denen ich die meisten sofort erfolgreich beheben konnte (beispielhaft: Symlinks bei Datensicherung/-wiederherstellung nicht bedacht). Und ich habe leider einen großen Bock geschossen: Ich habe 14 Skripte verloren, an denen meine Vorgänger und ich fleißig gebastelt haben. Es sind dies:

  • 3 x Datensicherung
  • 5 x Titelbilder und Innenillus vom Verlagsserver kopieren
  • 2 x UserCreates
  • 4 x Most_viewed und Total_Views

Da gibt es nichts zu beschönigen, das ist großer Mist. Zum Glück nicht sehr bedrohlich, für den Normalbetrieb gibt es keine Einschränkungen. Nur die genannten Services stehen vorübergehend nicht zur Verfügung. Ab morgen werde ich anfangen, mich um die Datensicherung zu kümmern, die logischerweise am wichtigsten ist; diese Skripte waren größtenteils von mir und entsprechend leicht stelle ich mir die Neuerstellung vor. Mein Fokus liegt dabei klar auf "status quo ante" - keine Experimente zum jetzigen Zeitpunkt.

Sollte euch sonst irgendetwas auffallen, was seit dem Serveraustausch Probleme macht: bitte unter Perrypedia:Beobachtete Fehler#Nach dem Serverwechsel... melden. Ich werde mich kümmern, sobald ich kann.

Es fällt auf, dass der neue Server wiederum, wie schon im Dezember, ein alter Server ist. Beide Festplatten notieren mit 54.000+ Betriebsstunden. Strato hat uns auf Anfrage bestätigt, dass gebrauchte Hardware stets wiederverwendet wird, sofern der technische Check grünes Licht gibt. Nach meiner Meinung kann man an dieser Geschäftspraxis absolut nichts beanstanden. Es kann niemand voraussagen, wie lange ein gebrauchtes Gerät problemlos läuft. Für uns war weder vorhersehbar, dass wir nach dem Plattenproblem im Dezember ein so betagtes Ersatzgerät bekommen, noch das erneute Plattenproblem nach nur sieben Monaten. Beides ist einfach auch dummer Zufall und hätte ganz anders kommen können. Da unser Vertrag bereits geraume Zeit läuft, ist es auch völlig legitim, dass wir Ersatzhardware nach dem damaligen technischen Stand bekommen. Das bedeutet aber auch, dass wir kaum eine Chance haben, ein jüngeres Gerät zu bekommen. Der nächste Plattenfehler ist nur eine Frage der Zeit. Jeweils den ganzen Server zu tauschen, ist unbefriedigend und ineffizient; der Sinn unserer RAID-1-Plattenspiegelung wird damit fast völlig zunichte gemacht. Strato bietet zwar auch den Austausch einzelner Komponenten an, dazu müssen aber kostenpflichtige Zusatzvereinbarungen (SLA = Service Level Agreement) abgeschlossen werden. Das ist aber wiederum nur eine von mehreren Möglichkeiten, wie wir die Situation verbessern können. Verschiedene Leute haben bereits signalisiert, dass sie Vorschläge haben. Wir wollen uns alles anhören und in Ruhe diskutieren und abwägen, was wir uns leisten können und wollen. Momentan bin ich zwar noch mit ein paar Nacharbeiten beschäftigt, aber es spricht nichts dagegen, jetzt bereits mit der Materialsammlung zu beginnen ... Fortsetzung bitte unter Perrypedia:Verbesserungsvorschläge. --Klenzy (Diskussion) 19:27, 17. Jul. 2019 (CEST)

Halten wir fest: wir haben zuerst einmal wieder ein funktionierendes System. Deshalb vielen Dank Klenzy für deine Bemühungen (aus dem Krankenstand von Null auf Hundert). Wenn es nach Aki gegangen wäre, hätte sie auf einem kranken System eine Update-Orgie veranstaltet und wir hätten mit Sicherheit auf Sicht ein riesen Problem erlebt. Aber lassen wir das und schauen nach vorne. Mit der aktuellen Situation können wir in der Tat nicht lange leben. Deshalb werde ich einige Gedanken unter Perrypedia:Verbesserungsvorschläge einbringen. --Norman (Diskussion) 00:00, 18. Jul. 2019 (CEST)
Auch von mir vielen Dank. In welchem preislichen Rahmen würde sich denn eine SLA-Zusatzvereinbarung bewegen? --Johannes Kreis (Diskussion) 06:55, 18. Jul. 2019 (CEST)
Ein ganz herzliches Dankeschön an Klenzy. --Jenka (Diskussion) 08:48, 18. Jul. 2019 (CEST)
Danke für deinen beherzten Einsatz, Klenzy! --Soulprayer (Diskussion) 10:05, 18. Jul. 2019 (CEST)

Anfangsverdacht auf Plattenproblem

Möglicherweise gibt es doch ein Problem mit einem der beiden Plattenlaufwerke. Ich habe zwar nach dem Serveraustausch im Dezember zur Überwachung der Platten wieder die Smartmontools installiert, dabei ist aber eine kleine Feinheit schiefgegangen. Auffällige Diagnosewerte hätten mir per Mail zugestellt werden sollen - aber ich habe den Mailversand verkehrt konfiguriert. Das habe ich jetzt beim Durchschauen der Syslogs (für eine der fraglichen Datensicherungs-Problemzeiten) entdeckt. Es gibt also ein paar auffällige Werte (Raw_Read_Error_Rate, Reallocated_Sector_Ct) bei der /dev/sdb. Das allein hat noch nicht viel zu bedeuten. Ich habe jetzt erst einmal einen ausführlichen Plattentest gestartet, der frühestens nach 2 Stunden - spätestens morgen Vormittag - eine Analyse liefern müsste.
Bevor das nicht geklärt ist, rate ich dringend von irgendwelchen Softwareupdates oder Konfigurationsänderungen ab. --Klenzy (Diskussion) 14:40, 12. Jul. 2019 (CEST)

Der Selbsttest hängt und kommt zu keinem Ende. Die Anzahl der defekten Sektoren ist seit gestern von 338 auf 380 gestiegen. Somit verdichten sich die Anzeichen für ein Plattenproblem. Einen Beweis dafür habe ich zwar nicht, aber die vereinzelten krassen Laufzeiten der Datensicherung und beim Speichern großer Artikel passen als Symptom haargenau zu einer kränkelnden Platte.
Als nächsten Schritt möchte ich einen "Captive"-Test machen, also im Vordergrund. Um einen möglichen Datenverlust zu vermeiden, setze ich die Perrypedia ab 16:00 Uhr auf Read-Only (Schreibsperre). --Klenzy (Diskussion) 14:54, 13. Jul. 2019 (CEST)
Normalbetrieb ist wieder freigegeben. --Klenzy (Diskussion) 20:02, 13. Jul. 2019 (CEST)
Jetzt fahre ich das nächstgrößere Geschütz auf. Wir machen ab 12:00 Uhr einen Strato-Hardwaretest. Deswegen nehme ich die Perrypedia für 3 bis 6 Stunden offline. --Klenzy (Diskussion) 11:10, 14. Jul. 2019 (CEST)
Wir haben eine defekte Festplatte und müssen deshalb im nächsten Schritt mit STRATO Kontakt aufnehmen. Der Betrieb geht momentan uneingeschränkt weiter. In den kommenden Tagen wird es wohl eine neue Festplatte oder gar wieder einen neuen Server geben. --Klenzy (Diskussion) 17:09, 14. Jul. 2019 (CEST)
Die Perrypedia bekommt einen anderen Server.
Ab heute 15:00 Uhr setze ich Read-Only/Schreibsperre für ein paar außerordentliche Datensicherungen. Voraussichtlich morgen früh geht es dann los mit dem Hardwaretausch, in dieser Zeit sind wir dann vollständig offline.
Vorschläge, um so etwas zukünftig zu vermeiden, gibt es bereits und werden wir nach dem erfolgreichen Hardwaretausch diskutieren. --Klenzy (Diskussion) 09:14, 15. Jul. 2019 (CEST)
Ich weiß die Frage ist ultra-gemein (ein bißchen Computer-affin bin ich schon): kann man einschätzen wie lange der Austausch dauert? Und ich bin froh, dass ihr euch um die Sicherheit der Daten sorgt. --Jenka (Diskussion) 09:35, 15. Jul. 2019 (CEST)
Kurz zur Info: [1]
Diesen Forumsthread nutze ich für Infos über die Perrypedia, vor allem auch dann, wenn die Perrypedia offline ist. --Klenzy (Diskussion) 09:47, 15. Jul. 2019 (CEST)
Prima, Danke. So ist man auf dem Laufenden. --Jenka (Diskussion) 09:51, 15. Jul. 2019 (CEST)
Los geht's. Ich beginne mit Schreibsperre und einer außerordentlichen Datensicherung. --Klenzy (Diskussion) 15:04, 15. Jul. 2019 (CEST)
Durch den Serveraustausch ist das Plattenproblem erledigt. Weiter geht es hier. --Klenzy (Diskussion) 18:40, 17. Jul. 2019 (CEST)

Datensicherung und Schreibsperre

Die Datensicherung läuft derzeit extrem lange, heute morgen etwa bis 7.15 Uhr. Die Schreibsperre muss bis zum Abschluss der Sicherung bleiben. Daher bitte nicht wundern, wenn ihr morgens mal noch nicht Ändern könnt. Ich schau mir das an, sobald ich wieder daheim bin. --Klenzy (Diskussion) 11:25, 4. Jul. 2019 (CEST)

Heute dauerte es schon bis 11:45 Uhr...und warum kümmert sich Aki nicht um diese Angelegenheit? --JoKaene 11:46, 7. Jul. 2019 (CEST)
Ich habe ihre Mailadresse noch nicht auf meinem Handy. Peinlich.
Info steht jetzt auch im Forum: https://forum.perry-rhodan.net/viewtopic.php?f=62&t=1609&start=400#p666844 --Klenzy (Diskussion) 14:07, 7. Jul. 2019 (CEST)
Ich hab' sie mal über die PP angeschrieben. --JoKaene 14:17, 7. Jul. 2019 (CEST)
Sorry, war die letzten Tage wieder mit der Arbeit völlig zu und konnte hier nicht reinschauen. Wenn irgendwas dringendes ist, schreibt mich bitte direkt z.B. auf aki@nofftz.name oder über die gängigen Messenger an. Eigentlich bin ich da ganz gut zu finden. --Aki 18:39, 8. Jul. 2019 (CEST)
Habe gerade mal einen Blick auf die Backup-Scripts geworfen. Da gibt's ein paar Tricks, wie sich diese beschleunigen lassen. Dann haben wir auch weniger Schreibsperre. Werde aber wohl erst am Wochenende dazu kommen, da optimieren zu können. Aber ich weiß ja jetzt Bescheid und werde das im Auge behalten. --Aki 18:42, 8. Jul. 2019 (CEST)
Also mir fällt seit Tagen auf, dass Updates auf größere Artikel teilweise sehr lange dauern. Wieder Problem ein mit den Platten im RAID ? --Norman (Diskussion) 07:02, 9. Jul. 2019 (CEST)
Ist mir auch aufgefallen. --Johannes Kreis (Diskussion) 07:53, 9. Jul. 2019 (CEST)
Okay, danke für die Hinweise. Dann prüfe ich das auch mal. Aber wie gesagt, das klappt erst zum Wochenende. Hatte gehofft, dass hier in der Firma langsam Sommerloch einkehrt, aber derzeit ist eher das Gegenteil der Fall. :( --Aki 13:38, 9. Jul. 2019 (CEST)
Hab kurz nachgeschaut. RAID ist in Ordnung. Allerdings müsste der Server rebootet werden. Das kann ich heute Abend machen, wenn kaum noch Leute unterwegs sind. Ansonsten bietet die Konfiguration einiges Potential zur Performance-Verbesserung – mache ich am Wochenende. --Aki 13:44, 9. Jul. 2019 (CEST)
So, Neustart ist durchgeführt. Derzeit ist es gefühlt etwas schneller, aber das Problem entsteht durch die derzeitige Lösung aus Apache und libphp, die nicht sehr gut unter Last skaliert [2]. Wir setzen inzwischen auf allen Systemen nginx und php-fpm ein, was erheblich schneller ist. Der zweite Flaschenhals ist die Datenbank, aber auch hier kann ich was tun. Werde die Perrypedia dafür mal kurz offline nehmen müssen, aber dann gebe ich rechtzeitig Bescheid. --Aki 01:00, 10. Jul. 2019 (CEST)
Nur eine Frage, @Aki: Bist Du sicher, dass genau diese Vorgehensweise genau angemessen ist für genau das beschriebene Problem? --Klenzy (Diskussion) 19:33, 10. Jul. 2019 (CEST)
Das ist eine etwas seltsame Frage. Ich habe die Konfiguration analysiert und schlage Verbesserungen vor, die 1. die Zeit von Datensicherungen von Stunden auf Minuten verringern und 2. die allgemeinen Reaktionszeiten verkürzen und Last (CPU/RAM) vom Server nehmen, wovon alle was haben. Insofern ist weniger die Frage, ob das angemessen ist, sondern eher, ob es das Risiko der Änderung(en) wert ist. Wir können auch gerne kleine Einzelschritte gehen. Dann könnt ihr jeweils bewerten, ob die Richtung sich lohnt. Alles auf einmal zu machen, wäre ohnehin nicht klug. Würde dann aber empfehlen mit dem Datenbank-Update anzufangen, um die Backup-Problematik nachhaltig zu lösen. --Aki 02:52, 11. Jul. 2019 (CEST)
Ich finde es gut, wenn ihr SysAdmins das untereinander einvernehmlich abwägt. Meine Erfahrungen aus meiner aktiven Berufszeit (Leiter IT) sind diese, dass eine Änderung an der Backup-Methodik (anders kann man solche Zeitersparnis nicht erzielen) immer auch damit einhergeht mit einem speziell darauf angepassten Recovery-Konzept. Und das sollte (wie ihr wißt) im Vorfeld auch gut erprobt und ausgetestet sein, bevor man das ändert. --Norman (Diskussion) 11:38, 11. Jul. 2019 (CEST)
Okay, dann gehe ich doch mehr in die technischen Details. Derzeit läuft das Backup so, dass aus der SQL-Datenbank genau die SQL-Befehle erzeugt werden, die nötig sind, um genau diese Datenbank wieder anzulegen. Das stammt noch aus meiner früheren Zeit und war damals die einzige Möglichkeit, so eine Datensicherung anzulegen. Inzwischen gibt's aber ein Tool, das die Daten, wie sich die Datenbank direkt verwendet, unmittelbar sichert. Für eine Wiederherstellung müssen diese Dateien dann lediglich zurück geschrieben werden. Schon an dieser Beschreibung seht ihr, dass das wesentlich simpler ist und damit auch schneller geht – in beiden Fällen. Da hier nur Daten kopiert werden, geht das sogar im laufenden Betrieb, d.h. wir könnten theoretisch sogar stündliche Backups machen, um das Risiko eines Datenverlustes zu minimieren. Wer sich für Details interessiert, kann ja mal hier rein schauen. Der Punkt ist aber, dass wir vom inzwischen doch recht eingestaubten MySQL zum legitimen Nachfolger MariaDB wechseln müssen. Da es dasselbe Programm ist und nur der Name sich aus rechtlichen Gründen ändern musste, ist das aber sehr einfach: MySQL runterfahren und deinstallieren, MariaDB installieren und hochfahren, fertig [3].
Zum anderen Thema: Auch hier ist das aus der Historie gewachsen. Damals war ein direkt im Apache laufender PHP-Interpreter state of the art und saumäßig schnell. Daran hat sich auch wenig geändert – bei kleinen Seiten. Bei größeren (und dazu gehört die Perrypedia nun mal) kommt aber der große Nachteil von Apache zum Tragen: Apache startet für jede Anfrage einen eigenen Thread. Das funktioniert wie gesagt bei kleineren Seiten super, aber bei vielen Anfragen wird immens viel CPU-Leistung und Arbeitsspeicher (RAM) blockiert, was das ganze System träge macht oder im schlimmsten Fall auch zu Fehlern/Ausfällen führen kann. Genau das ist bei der Perrypedia schon oft passiert. Meistens repariert sich das von selbst wieder, wenn die Last sinkt, aber halt nicht immer. PHP-FPM (Fast Process Manager) verfolgt einen anderen Ansatz. Hier gibt's verschiedene Threads (Worker), die ständig laufen und nach Bedarf die Anfragen abarbeiten. Es können auch dynamisch Worker hinzugenommen oder geschlossen werden, um auf Lastspitzen zu reagieren. Vergleichbar im realen Leben sind z.B. die Schlangen an der Supermarktkasse, wo du dich irgendwo anstellst und dich dann ärgerst, dass es woanders schneller geht (Apache mit mod_php) oder das System, das etwa die Bahn seit einiger Zeit verwendet, wo du einfach eine Wartenummer ziehst und dich dann zum nächstbesten freien Schalter wendest, was sehr viel schneller geht und alle Schalter gleichmäßig auslastet (PHP-FPM). Wenn du danach noch den Apache durch den wesentlich schlankeren nginx ersetzt, der außerdem noch ein paar nette Cache-Fähigkeiten mitbringt, gelangen einige Anfragen – etwa von reinen Lesezugriffen – gar nicht mehr erst ins PHP oder die Datenbank rein, was zusätzlich Kapazität einspart.
Ich hoffe, dass das mit diesen Erläuterungen alles etwas klarer geworden wird. Also die Frage nach Angemessenheit ist einfach komplett falsch gestellt. Die korrekte Frage wäre, ob wir diese Umstellungen machen wollen, um insgesamt das System schneller und ausfallsicherer machen zu können.
--Aki 14:04, 11. Jul. 2019 (CEST)
Bisher hatte ich keinen Insight auf den Backend der Perrypedia, aber Aki's Ausführung und Argumentation ist hieb- und stichfest. Bin ja selber in der IT tätig und kann das einschätzen. Ich persönlich würd zwar noch sicherheitshalber ein Backup der alten Konfiguration machen, aber nevertheless ist nach dieser langen Erklärung auch meine Meinung, dass dieses Upgrade notwendig ist. --Soulprayer (Diskussion) 15:18, 11. Jul. 2019 (CEST)
@Aki: Es geht hier weniger um Technik sondern um ein paar (eigentlich selbstverständliche) Prinzipien, die meiner Meinung nach fahrlässig mißachtet werden!
1.) Solche Änderung bedürfen im Vorfeld sorgfältiger Tests. Frage: Wann hast du das alles auf dem Testsystem ausgetestet?
2.) Das Vorgehen gleicht einer Art Hauruck-Aktion, obwohl keine zwingende Notlage vorliegt. Dies birgt viel zu viel Risiko für die PP. Deshalb bitte "Safty-first".
3.) Mir gefällt nicht, dass das alles ohne Absprache mit Klenzy durchgeführt werden soll. Das finde ich alles andere als kollegal! Warum diese Eile? (Vollgemerkt wir haben keinen Krisenfall)
4.) Deshalb bin ich entschieden dagegen, dass dieses an diesem Wochenende so durchgeführt werden soll. Wir sind doch ein Team und hierzu gehört auch dass man wichtige Dinge miteinander im Vorfeld bespricht.
--Norman (Diskussion) 17:32, 11. Jul. 2019 (CEST)
Es gibt das Problem, dass die Backups bis in den Vormittag rein laufen. Dafür habe ich eine Lösung präsentiert und auch erklärt, welche weiteren Verbesserungen noch möglich wären. Das mit dem Backup kann ich durch das Datenbank-Update kurzfristig lösen. Den Rest hatte ich zur Diskussion gestellt. Und glaubst du ernsthaft, dass ich auch nur eine Änderung ohne Tests durchführen würde? Ich habe beruflich mit Server-Systemen zu tun, über die sechs- bis siebenstellige Umsätze laufen. Da wird nichts irgendwie „Hauruck“ gemacht. Dieselbe Sorgfalt wende ich auch hier an. --Aki 18:46, 11. Jul. 2019 (CEST)
Meine gesammelten Gedanken dazu gehen dir gleich schriftlich zu. --Klenzy (Diskussion) 10:56, 12. Jul. 2019 (CEST)

Serverausfall

Der heutige Ausfall ab 11.00 Uhr ist darauf zurückzuführen, dass Strato für Wartungsarbeiten am Rechenzentrtum den Strom abgeschaltet hat. Es war angekündigt, aber als ich das Mail auf mein Handy bekommen habe, waren wir schon auf dem Weg in den Süden. Und danach habe ich es schlicht vergessen, euch zu informieren. --Klenzy (Diskussion) 12:23, 27. Mai 2019 (CEST)

Alles gut! Die PP läuft ja schon wieder. Ich wünsche dir einen schönen Urlaub! --Johannes Kreis (Diskussion) 12:33, 27. Mai 2019 (CEST)

Artikelanzahl

Heute bekommen wir 50 Artikel geschenkt. Die Artikelanzahl ist ein Zähler in irgendeiner Statistiktabelle, der bei einem neuen Artikel, Löschungen, Verschiebungen etc. jeweils aktualisiert wird. Die komplette Neuzählung ergibt demgegenüber 50 Stück mehr, ganz ohne den sonst üblichen Aufwand für neue Artikel ;-) --Klenzy (Diskussion) 10:16, 7. Feb. 2019 (CET)

Testwiki wird aktualisiert 01/19

Ich werde nächstes Wochenende 26.-27.01.19 das Testwiki plätten und neu aufsetzen. Wenn ihr also dort im Testwiki etwas habt, das ihr in Sicherheit bringen müsst, dann ist noch bis Samstag vormittag Zeit dafür. Nach der Datenübernahme werde ich dort die Namensraum-Erweiterung für die Strukturierten Diskussionen ausprobieren. --Klenzy (Diskussion) 20:53, 24. Jan. 2019 (CET)

Das Testwiki ist ab jetzt gesperrt. --Klenzy (Diskussion) 10:30, 26. Jan. 2019 (CET)
Das Testwiki ist derzeit kaputt. Aufgrund eines Programmfehlers lässt sich die Datensicherung nicht einspielen. --Klenzy (Diskussion) 14:11, 26. Jan. 2019 (CET)
Fast vergessen zu erwähnen: Das Testwiki ist wieder da. Es gab ein Problem bei der Datensicherung und -wiederherstellung, das jetzt behoben ist. --Klenzy (Diskussion) 12:52, 29. Jan. 2019 (CET)