Mark Bluhm Senior VP und CTO, Shared Services Thomson Reuters Professional Division

Bei Thomson Reuters ist es unsere Mission, die vielfältigen Informationsanforderungen von Unternehmen und Fachleuten zu erfüllen. Informationstechnologie ist daher ein zentraler Aspekt bei all unseren Tätigkeiten. Die Ursprünge unseres aktuellen IT-Ansatzes liegen bereits über zehn Jahre zurück. Zu dieser Zeit sahen wir uns mit Stabilitätsproblemen bei unserem Online-Service für juristische Recherche, Westlaw, konfrontiert.

Damals – vor dem Internetboom – war Westlaw noch eine Mainframe-basierte Rechtsplattform und wir standen vor der Gefahr, talentierte Software-Ingenieure zu verlieren, die mit neueren Technologien arbeiten wollten. Ich wurde beauftragt, eine neue, offene Infrastruktur für Westlaw zu schaffen und zwar so, dass diese Infrastruktur auch für unsere anderen Datenunternehmen hilfreich sein würde. Es stellte sich als zukunftsweisende Aufgabe heraus, mit standardisierten Bausteinen eine Shared IT-Infrastruktur zu erstellen.

Diese einfache Anweisung war der Beginn einer stetigen, langjährigen IT-Entwicklung und führte kürzlich zu der erfolgreichen Veröffentlichung eines vollkommen neuen juristischen Recherche-Services der nächsten Generation: WestlawNext. Dank unserer Infrastruktur ist es uns gelungen, den Support für WestlawNext zu erweitern und gleichzeitig durch 25 % weniger Stromverbrauch ca. 65 Millionen US-Dollar bei neuen Datacenter-Kosten einzusparen sowie tägliche Verfügbarkeit rund um die Uhr zu gewährleisten. WestlawNext ist in der Lage, im Vergleich zur vorherigen Generation 50-mal mehr Daten (5 Milliarden Dokumente) zu durchsuchen und doppelt so schnell Ergebnisse zu liefern.

In diesem Artikel möchte ich einige der wichtigsten Elemente dieser Infrastruktur darstellen, darunter Bausteine, unsere zentrale Sucharchitektur und unser virtualisiertes Front-End. NetApp und NetApp Professional Services standen uns bei dieser Herausforderung als wertvolle Partner zur Seite. Dies soll daher auch entsprechend gewürdigt werden.

Eine Shared IT-Infrastruktur für die Recherche

Der Schlüssel zum Erfolg für WestlawNext und alle Produkte von Thomson Reuters liegt darin, in enormen Datenmengen Suchen schnell und mit absoluter Genauigkeit durchzuführen. Wenn zwei Personen die gleiche Suche zur gleichen Zeit durchführen, müssten sie genau die gleichen Ergebnisse erhalten.

Durch Verbesserungen unserer Suchmethoden bei WestlawNext haben wir Anwendern ermöglicht, in einfachem Englisch nach dem Gesuchten zu fragen. Sie brauchen keine "formelle" Frage mehr zu formulieren. Eine Anfrage, die vor zwei oder drei Jahren nur eine Suche generierte, ergibt nun 40 oder mehr Suchen am Back-End. Darüber hinaus ist unsere Infrastruktur weiter skalierbar, um diesem Workload zu entsprechen, was absolut fantastisch ist. Wir haben damit weit mehr erreicht, als wir ursprünglich geplant hatten. Eine durchschnittliche Suche gibt in nur 2,5 Sekunden Daten an den Kunden aus.

Zu den zentralen Elementen unserer Infrastruktur zählen:

• Standard-Bausteine
• eine Cloud-ähnliche Sucharchitektur
• virtualisiertes Web Front-End
• Replizierung für Disaster Recovery

Standard-Bausteine
Unsere Infrastruktur setzt sich aus zahlreichen Standard-Bausteinen zusammen. Wir verfügen in unseren Datacentern über 25.000 bis 30.000 x86 Server, davon sind die meisten mit 2- oder 4-CPU-Konfigurationen ausgestattet und durch NetApp Storage gesichert. Unsere Netzwerkinfrastruktur besteht fast ausschließlich aus 10-Gigabit-Ethernet mit Cisco 6500 und Cisco Nexus 5000 sowie Switches der 7000 Serie. Wir verwenden diese Bausteine sowohl in den Front-End- als auch in Back-End-Konfigurationen.

Abbildung 1) Bemerkenswerte Leistungen bei der IT-Transformation von WestlawNext und Thomson Reuters

Novus: Cloud-ähnliche Infrastruktur für die Recherche
Unsere Novus Architektur, die im Jahr 2006 patentiert wurde ist das Herzstück aller Suchvorgänge. Die Novus Architektur bietet eine einzelne Plattform zur Unterstützung der Online Services von allen vier Marktbereichen bei Thomson, darunter WestlawNext und Checkpoint, unser Recherchesystem für Steuer- und Rechnungswesen. Insgesamt wird die Novus Architektur von über 30 Applikationen verwendet.

Das Novus System ist eine dezentrale Sucharchitektur, die auf Tausenden von SUSE Linux Servern basiert, auf denen jeweils unsere unternehmenseigene Software ausgeführt wird. Jeder Such-Server ist für einen Teil des gesamten Content-Index verantwortlich. Dieser kann im Server-Speicher abgelegt werden und ist daher äußerst schnell abrufbar. Wenn eine Suche ausgeführt wird, sind Tausende von Machines gleichzeitig im Einsatz. Die Ergebnisse werden zurück an den Controller gesendet. Hier werden sie sortiert, kombiniert, klassifiziert und die daraus resultierenden Informationen gehen zurück zur Applikation, von der die Anfrage gestellt wurde. So erhalten wir Suchergebnisse im Bruchteil einer Sekunde.

Die Applikation entscheidet dann, ob sie die bei der Suche ermittelten Dokumente abrufen möchte. Die Content Stores kommen erst zum Einsatz, wenn ein Dokument angefragt wird. Der Content selbst wird mithilfe Hunderter Oracle RAC Datenbank-Clustern gespeichert, die standardmäßig über vier Knoten pro Cluster verfügen. Jeder Cluster beherbergt eine Teilmenge des gesamten Content.

Ich weiß, dass der Begriff "Cloud" verschiedene Bedeutungen haben kann. Novus ist jedoch darauf ausgerichtet, die gewöhnlich einer Cloud-Infrastruktur zugeschriebene Flexibilität zu liefern, obwohl die Infrastruktur konzipiert wurde, bevor der Cloud-Begriff populär wurde. Alle Server in der Novus Umgebung können in Echtzeit neu zugewiesen werden und eine andere Funktion übernehmen. Bei der Konzipierung dieser Architektur wollten wir sicherstellen, dass wir im Falle einer Spitzenauslastung Ressourcen sehr schnell neu zuordnen und so einen Datenbank-Server innerhalb kürzester Zeit in einen Such-Server umwandeln können.

Wenn wir Code-Implementierungen bei Novus vornehmen, wird jeder Code auf jedem Server und für jede Funktion implementiert. Das heißt, wir müssen nur eine einzelne Einstellung ändern und sagen: "Server A, du bist kein Such-Server mehr, sondern ein Load Server."

Wenn WestlawNext stark beansprucht wird, können wir diesem System, Checkpoint oder einer beliebigen anderen Applikation, das Ressourcen benötigt, mehr Ressourcen zuweisen. Die Server müssen nicht neu gestartet werden. Die entsprechenden Indizes werden einfach auf NetApp Storage geladen und schon sind die Server für ihre neue Rolle bereit. Mehrere Server-Sätze können dem gleichen Indexsatz zugewiesen werden, um die parallele Funktionsweise zu optimieren und die weitere Skalierbarkeit von Novus zu ermöglichen.

Diese Dynamik schafft Redundanz in der Umgebung und sorgt für die Exaktheit der Ergebnisse. Wir halten stets zusätzliche leerlaufende Server bereit. Wenn wir innerhalb weniger Millisekunden nach Senden einer Anfrage von einem Server kein Ergebnis erhalten, führen wir einige Schnelltests an diesem Server durch. Wenn er nicht reagiert, langsam ist oder ein anderes Problem aufweist, wird automatisch ein anderer Server zugewiesen, der diese Rolle übernimmt. Er lädt den entsprechenden Index auf den Speicher und führt die Anfrage aus.

Im Endergebnis bedeutet dies: Auch wenn ein Server ausfällt, erhält der Anwender ein exaktes und vollständiges Ergebnis mit nur wenigen Sekunden Verzögerung. Der Anwender muss die Anfrage nicht erneut senden und die Recovery erfolgt automatisch ohne Eingreifen des Administrators. Beim Novus Content selbst sorgt Oracle RAC für Redundanz. Wenn ein RAC Server ausfällt, übernimmt ein anderer Knoten im Cluster seine Funktion. Bei starker Auslastung eines RAC Clusters können wir dynamisch mehr Knoten hinzufügen, um die Auslastung auszugleichen.

Virtualisiertes Front-End
Für das gesamte Front-End – alles außerhalb von Novus – verwenden wir eine viel typischere Umgebung aus Web Servern und mehreren Applikations-Servern. Abgesehen von den Recherchen greift das Applikations-Tier auch auf zahlreiche andere Bereiche von Novus zu, die für diese Analyse nicht relevant sind. Dazu zählen Sicherheitsdatenbanken, Benutzerdaten, Rechnungsdatenbanken und MIS-Daten, also alles, was eine normale Applikation braucht.

Ein großer Teil der Front-End-Umgebung wurde mit VMware virtualisiert. Die meisten Web und Applikations-Server laufen auf Virtual Machines. VMware ermöglicht uns die gleiche dynamische Ressourcenzuteilung am Front-End, die wir innerhalb von Novus vornehmen. Wir können die Anzahl der Web und Applikations-Server für jede Applikation nach Bedarf anpassen.

Darüber hinaus erreichen wir mit VMware einen unterbrechungsfreien Betrieb. VMware HA schützt vor Ausfällen der Virtual Machines und mit vMotion können wir Wartungsarbeiten und andere Prozesse ohne Ausfallzeiten und Verluste aktueller Daten durchführen, was bisher nicht möglich war. Wenn ich vor der Virtualisierung einen Server mit 100 Anwendern warten wollte, musste ich alle Anwender offline setzen und später wieder anmelden oder mir eine spezielle Programmierung überlegen, was nahezu unmöglich war.

Mit VMware lassen sich Wartungsarbeiten je nach Bedarf im Laufe des Tages durchführen, da wir die VMs einfach auf Aushilfs-Servern ausführen und die Wartungsarbeiten dann auf den Original-Servern vornehmen können.

Disaster Recovery
Ich habe bereits erklärt, wie wir Redundanz in einem Datacenter gewährleisten. Das Disaster Recovery (DR) allerdings habe ich außen vorgelassen, um die Sache nicht zu kompliziert zu machen. Bei üblichen Betriebsbedingungen haben wir immer zwei Datacenter mit einer sehr ähnlichen Infrastruktur und nahezu identischen Daten. Falls eines der Datacenter ausfällt, kann das andere Datacenter entsprechend skaliert werden, um den zusätzlichen Such-Workload zu bewältigen.

Mithilfe von Replizierung halten wir unsere Datacenter synchron. Wir haben für unsere Novus Indizes unseren eigenen Replizierungsmechanismus entwickelt. So stellen wir sicher, dass unsere Datacenter vollkommen synchron sind. Die Content Stores in unseren Oracle RAC Datenbanken werden mithilfe von Oracle DataGuard repliziert.

NetApp macht den Unterschied

NetApp unterstützt sowohl die Novus Architektur (Indizes und Oracle RAC Content Stores) als auch die Front-End VMware Umgebung. Alle Indizes, die in unsere Linux Server gezogen werden sowie der gesamte in Oracle RAC gespeicherte Inhalt werden auf NetApp NAS Storage aufbewahrt und sind über NFS zugänglich. Novus würde einfach nicht funktionieren, wenn wir nicht Tausende Server hätten, die sich den Zugriff auf unsere Storage-Systeme teilen und wir nicht ständig dynamisch ändern könnten, welche Server auf welchen Storage on-the-fly zugreifen. NetApp machte den Unterschied für uns, als wir das System zum ersten Mal im Jahr 2002 implementierten. Und es ist bis heute ein wesentlicher Bestandteil unserer Lösung.

Um die Skalierungs- und Performance-Anforderungen von WestlawNext zu unterstützen, haben wir kürzlich einige Infrastrukturverbesserungen vorgenommen. Wir fügten Flash Cache zu wichtigen NetApp Systemen hinzu. Genauergesagt verwenden wir es für NetApp Systeme, die Storage für einen einzelnen Oracle RAC Cluster liefern. Solche Cluster verfügen oft über eine geringe Kapazität und hohe Performance-Anforderungen. Dank Flash Cache halten wir die Performance auf hohem Niveau, müssen aber keine Spindeln hinzufügen und Kapazität verschwenden, um die erforderliche Leistung zu erzielen. Außerdem verwenden wir Flash Cache nun auch auf Shared Storage-Systemen, die unseren Linux Kunden Indizes und andere Daten liefern. Erste Tests lassen uns annehmen, dass es hier eine ähnlich große Auswirkung hat.

Wie Sie sicher wissen, fügen wir ständig neuen Inhalt hinzu. Das bedeutet, es müssen ständig neue Indizes erstellt werden und der neue Content muss mit den entsprechenden Indizes veröffentlicht werden, während wir gleichzeitig alles synchron halten müssen. Falls ein Problem auftritt und wir einen früheren Zustand wiederherstellen müssen, dann muss dies so schnell wie möglich erfolgen. Die NetApp SnapRestore Technologie ist hierfür mit Abstand die beste Lösung.

Bevor wir Inhalt laden, erstellen wir eine Snapshot Kopie. Wenn wir dann einen früheren Zustand wiederherstellen müssen, können wir mit SnapRestore ganz einfach den Storage – zuerst in einem Datacenter und dann im anderen – in den vorherigen Zustand zurückversetzen. (In einigen Fällen müssen für Datenbanken Logs wieder eingespielt werden.)

In unserer VMware Umgebung verwenden wir NetApp Deduplizierung, um die Duplizierung zu eliminieren, die mit der großen Anzahl an identischen VMs einhergeht. Eine Abteilung führt allein mehr als 9.000 VMware VMs auf NetApp Storage aus. Mithilfe der Deduplizierung haben wir auf Primär-Storage Platzeinsparungen von über 160 TB erzielt.

Wir managen unsere Umgebung mit der NetApp OnCommand Produktreihe, einschließlich Operations Manager, Provisioning Manager, Performance Manager und OnCommand Insight. So verfügen wir über einen einheitlichen Satz an Tools, die über unseren gesamten NetApp Storage hinweg funktionieren. Das Ergebnis sind ein vereinfachtes Management, schnelle Provisionierung und die Erkennung von Performance-Problemen. OnCommand Insight (ehemals NetApp SANscreen) bietet uns eine konsolidierte Ansicht unserer gesamten heterogenen Storage-Umgebung und liefert Informationen bezüglich Kapazität, Konnektivität, Konfigurationen und Performance. Zusätzlich generiert es Alarme bei Ausfällen von Komponenten. So können wir Probleme beheben, bevor es bei redundanten Komponenten zu einem zweiten Ausfall kommt.

Mit weniger Aufwand mehr erreichen

Ich habe die enormen Effizienz- und Skalierungsvorteile bereits erwähnt, die wir durch die Implementierung von WestlawNext und anderen Services in der bereits beschriebenen Infrastruktur erzielt haben. Durch die gemeinsame Nutzung der Infrastruktur am Back-End können wir die Spitzenanforderungen unserer zahlreichen Applikationen effizient erfüllen, indem wir Ressourcen nach Bedarf zuweisen und gleichzeitig leerlaufende Ressourcen auf ein Minimum beschränken. Mit der Virtualisierung am Front-End könnten wir die Anzahl der Server und die damit verbundene Infrastruktur reduzieren. Aufgrund all unserer Bemühungen konnten wir die Einrichtung eines weiteren Datacenters bisher umgehen. NetApp Storage-Technologien, einschließlich Snapshot Kopien, SnapRestore, Flash Cache und die umfassende Suite an Management-Funktionen, helfen uns, die Storage-Auslastung zu optimieren und Engpässe zu eliminieren.

Für uns als Unternehmen ist die Partnerschaft mit NetApp ebenso wichtig für unseren Erfolg wie die NetApp Technologie. Von allen Anbietern, mit denen wir zusammenarbeiten, bezeichnen wir nur zwei als strategische Technologiepartner – einer davon ist NetApp. Probleme werden umgehend behoben und NetApp ist jederzeit bereit, uns bei wichtigen Technologieinitiativen wie WestlawNext zu unterstützen. NetApp hat eng mit uns zusammengearbeitet, um die Performance zu optimieren und schnell von den neuen Storage-Funktionen zu profitieren.

 Ihre Meinung zur Thomson Reuters Fallstudie?

Stellen Sie Fragen, tauschen Sie Ideen aus und teilen Sie Ihre Meinung mit der NetApp Community!

Tech OnTap
Melden Sie sich jetzt an.
Tech OnTap liefert jeden Monat Einblicke in die IT-Welt sowie exklusive Best Practices, Tipps und Tools, Interviews mit Entwicklern, Demos, Testberichte und vieles mehr.

Besuchen Sie die Website um sich noch heute anzumelden.