Möchten Sie erfahren, wie wir das veranstalten? ORCID Registry und APIs? Möchten Sie wissen, wie wir im Katastrophenfall mit Hochverfügbarkeit, Skalierbarkeit und Wiederherstellung umgehen? Wenn ja, dann ist dieser Beitrag genau das Richtige für Sie!
Wir verarbeiten jeden Monat acht Millionen Seitenaufrufe auf der ORCID Registry, aber der Großteil unseres Datenverkehrs läuft über die APIs, die derzeit über 100 Millionen Zugriffe pro Monat verzeichnen. Eine unserer Kernstrategien besteht darin, in die Entwicklung einer robusten Informationsinfrastruktur zu investieren. Daher müssen wir darauf vertrauen können, dass die Technologie, die wir zur Unterstützung dieser Nutzung verwenden, zuverlässig und sicher ist.
Das Register und der Rest der Website auf orcid.org werden über ein Content Delivery Network (CDN) weitergeleitet – einen Cloud-Dienstanbieter mit mehr als 150 Rechenzentren auf der ganzen Welt. Wenn Ihr Browser eine Verbindung herstellt orcid.org werden die statischen Teile der Website von einem lokalen Rechenzentrum in Ihrer Nähe bereitgestellt, um schnellere Ladezeiten zu ermöglichen.
Das CDN verfügt über einige weitere nützliche Funktionen, beispielsweise den Schutz vor Distributed Denial of Service (DDoS)-Angriffeund Echtzeit-Sicherheitsscans gegen Hacking-Bedrohungen.
Die Registrierungsseiten werden in unserem Hauptrechenzentrum gehostet, wo der Datenverkehr über einen Cluster von App-Servern lastenverteilt wird, während die Registrierungsdaten in einem Cluster aus drei leistungsstarken Datenbankservern auf verschlüsselten Dateisystemen gespeichert werden. Eine davon ist eine Masterdatenbank, in der Aktualisierungen vorgenommen werden, und zwei sind Replikaserver, die in Echtzeit eine Kopie der Daten erhalten. Die Replikatserver werden für die meisten „Lese“-Vorgänge der Registrierung und der APIs verwendet, sind aber auch Hot-Standby-Server, was bedeutet, dass sie im Falle eines Fehlers zum Master befördert werden können.
Wir verfügen über eine Reihe anderer Server, die das Produktionssystem unterstützen, die Daten verschieben, um Suchindizes zu erstellen, einen aktuellen Speicherauszug öffentlicher Daten in einem anderen Rechenzentrum aufbewahren und geplante Aufgaben wie E-Mail-Erinnerungen ausführen.
Wir sichern die Datenbank automatisch zweimal täglich, verschlüsseln den Dump und übertragen ihn an einen anderen Cloud-Dienstanbieter auf einem anderen Kontinent, damit wir im Falle einer Katastrophe in unserem Hauptrechenzentrum das Datenbank-Backup zur Wiederherstellung des Systems verwenden können. Wir testen regelmäßig, ob dieser Prozess mithilfe eines temporären Offline-Servers funktioniert.
Das ist eine solide Basis. Jedoch, ORCiD wächst weiter und wir werden zunehmend als Teil der Forschungsinformationsinfrastruktur eingesetzt. Deshalb müssen wir mehr tun, um sicherzustellen, dass sich die Gemeinschaft weiterhin auf uns verlassen kann.
Was möchten wir verbessern?
Wir möchten App-Server und Datenbankrepliken an mehreren Standorten haben, damit wir uns nicht auf den etwas langwierigen Datenbankwiederherstellungsprozess verlassen müssen oder Daten seit der letzten Sicherung verlieren. Im Falle eines plötzlichen Anstiegs der Nachfrage möchten wir in der Lage sein, neue Server innerhalb von Minuten statt Stunden bereitzustellen.
Wir erwägen die Trennung der kritischsten Teile des Systems wie Registrierung, Anmeldung und Autorisierung in einem isolierten System und möchten außerdem sicherstellen, dass Probleme mit dem öffentlichen API-Verkehr keine Auswirkungen auf die Registrierungs- und Mitglieds-APIs haben.
Und wir wünschen uns eine flexiblere Architektur unter Verwendung branchenüblicher Technologien wie z Docker-Container und Kubernetes, was uns dabei helfen wird, die oben genannten Verbesserungen vorzunehmen.
Sagen Sie uns, was Sie von unseren Plänen halten! Wie schneiden wir im Vergleich zu Ihrer eigenen Organisation und anderen Diensten ab, auf die Sie angewiesen sind? Können oder sollten wir noch mehr tun? Können Sie uns aus eigener Erfahrung einen Rat geben? Kontakt mit eurem Input und Feedback!