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

Vi på Thomson Reuters har som mål att uppfylla informationsbehoven för företag och yrkesverksamma inom ett brett urval av områden, så informationsteknik är viktigt i allt vi gör. För över 10 år sedan la vi grunden till vår nuvarande IT-inriktning när vi började märka instabilitet i vår webbaserade juridiktjänst, Westlaw.

Vid den tiden, och det här var innan dotcom-bubblan sprack, var Westlaw fortfarande en stordatorbaserad plattform av äldre modell och vi förlorade begåvade programtekniker som ville arbeta med nyare teknik. Jag fick uppgiften att skapa en ny, öppen infrastruktur för Westlaw och att göra det så att samma infrastruktur kunde användas för att stödja våra andra typer av informationsverksamhet. Det här visade sig vara en ganska framsynt lösning för att skapa en delad infrastruktur med byggstenar av standardmodell.

Det här enkla direktivet ledde in oss på en väg av stadig IT-utveckling under årens lopp som bidrog till en framgångsrik utgivning av en helt ny juridiktjänst, WestlawNext. Vår infrastruktur gjorde att vi kunde tillföra support för WestlawNext samtidigt som vi kunde undvika uppskattningsvis 65 miljoner dollar i kostnader för nya datacenter. Den drar 25 % mindre energi och vi kan erbjuda tillgänglighet dygnet runt alla dagar i veckan året om. WestlawNext kan genomsöka 50 gånger mer data (5 miljarder dokument) jämfört med föregående generation och kan returnera resultat dubbelt så snabbt.

I den här artikeln vill jag belysa några viktiga element i den infrastrukturen, inklusive byggstenarna, vår kärnsökarkitektur och vår virtualiserade frontend. NetApp och NetApp Professional Services fungerade som ovärderliga partners i det här arbetet, så jag kommer även att försöka ge dem ett erkännande för detta när så är aktuellt.

En delad IT-infrastruktur för sökning

Nyckeln till framgång för WestlawNext och alla Thomson Reuters produkter är att kunna utföra sökningar på enorma mängder data väldigt snabbt och med exakthet. Om två personer utför samma sökning samtidigt, ska de få exakt samma resultat.

Genom de förbättringar som vi har gjort av våra sökmetoder i WestlawNext behöver användare bara skriva vad de vill ha fram. De behöver inte längre kunna konstruera formella sökfrågor. Resultatet blir att en fråga som bara gav en sökning för två eller tre år sedan, nu genererar minst 40 sökningar i backend. Vad som är ännu mer anmärkningsvärt är att vår infrastruktur fortfarande kan anpassa skalan för att klara den här belastningen. Den klarar otroligt mycket mer än vad vi ursprungligen hade som mål för den. Vid en normal sökning tar det ungefär 2,5 sekunder att returnera data till klienten.

Huvudelementen i vår infrastruktur är följande:

• Byggstenar av standardmodell
• En molnliknande sökarkitektur
• Virtualiserad webb-frontend
• Replikering för katastrofåterställning

Byggstenar av standardmodell
Vår infrastruktur består av byggstenar som måste sägas vara av standardmodell. Vi har mellan 25 000 och 30 000 x86-servrar i våra datacenter. De flesta har konfigurationer med 2 eller 4 processorer och backas upp av NetApp®-lagring. Nästan hela vår nätverksinfrastruktur är 10 gigabitars Ethernet som använder switchar från Cisco 6500-, Cisco Nexus 5000- och 7000-familjerna. Vi använder de här byggstenarna i både frontend- och backend-konfigurationerna.

Bild 1) Viktiga framgångar för WestlawNext och förändringen av Thomson Reuters IT

Novus: Molnliknande infrastruktur för sökning
Vår Novus-arkitektur, som patentskyddades 2006, utgör kärnan i alla sökoperationer. Novus-arkitekturen erbjuder en enskild plattform för att stödja onlinetjänster från de fyra Thomson-marknadsgrupperna, inklusive WestlawNext och vårt skatt- och redovisningssystem Checkpoint®. Totalt använder över 30 program Novus-arkitekturen.

Novus-systemet är en distribuerad sökarkitektur som använder tusentals SUSE Linux®-servrar och där varje server kör vår egen programvara. Varje sökserver ansvarar för en del av det övergripande innehållsindexet, som ryms i serverminnet så att det går att komma åt extremt snabbt. När en sökning utförs når den tusentals datorer samtidigt. Resultaten skickas tillbaka till en styrenhet, som sorterar dem, sammanräknar dem, rangordnar dem och sedan skickar informationen tillbaka till programmet som har begärt dem. Genom att göra på det här sättet kan vi få en sökning som inte ens tar en sekund att utföra.

Programmet bestämmer sedan om dokumenten som har identifierats i sökningen ska hämtas. Innehållslagren rörs inte förrän ett dokument efterfrågas. Själva innehållet lagras med hjälp av hundratals Oracle® RAC-databaskluster, som normalt har fyra noder per kluster. Varje kluster innehåller en delmängd av det totala innehållet.

Jag är medveten om att begreppet "moln" betyder olika saker för olika människor, men Novus är utformat för att leverera samma flexibilitet som normalt tillskrivs molninfrastrukturer även om Novus-infrastrukturen utvecklades innan begreppet moln blev populärt. Valfri server i Novus-miljön kan omallokeras i realtid till att fylla en annan funktion. När vi utarbetade arkitekturen på det här sättet ville vi vara säkra på att det vid hög belastning skulle gå att omallokera resurser väldigt snabbt. Det skulle till exempel kunna vara så att en dator som agerade databasserver för fem minuter sedan, nu skulle agera sökserver.

När vi distribuerar kod till Novus distribueras all kod till alla servrar för alla funktioner. Så allt vi behöver göra är att ändra en enda inställning och ange att "Server A, du är inte längre sökserver, du är belastningsserver".

Om WestlawNext hårdbelastas kan vi allokera fler resurser specifikt till WestlawNext, eller till Checkpoint eller till något annat program som behöver resurser. Servrar behöver inte startas om. De läser bara in lämpliga index i minnet från NetApp-lagringssystemet, så kan de börja arbeta i sin nya roll. Flera uppsättningar av servrar kan tilldelas till samma uppsättning av index för att öka parallellt arbete så att Novus kan fortsätta att anpassa skalan.

Den här dynamiska förmågan gör även att vi kan bygga in redundans i miljön samt att den garanterar exakta resultat. Vi har alltid lediga extraservrar tillgängliga. Om vi inte får tillbaka något svar från en server inom några millisekunder efter att en begäran har gått ut, gör vi några snabba tester av servern. Om den inte svarar, är långsam eller har något annat problem, tilldelas automatiskt en annan server till den rollen. Den läser sedan in lämpligt index i minnet och uppfyller begäran.

Slutresultatet blir att en server kan uppvisa fel, men användaren kommer ändå att få korrekt resultat utan att något utelämnas och med bara några sekunders fördröjning. Användaren behöver inte skicka iväg någon ny begäran och återställningen sker automatiskt utan att administratören behöver gripa in. För själva Novus-innehållet tillhandahålls redundans genom användningen av Oracle RAC. Om en RAC-server uppvisar fel, övertar en annan nod i klustret dess funktion. Om ett RAC-kluster hårdbelastas kan vi dynamiskt lägga till fler noder för att möta belastningen.

Virtualiserad webb-frontend
För allt i frontend – allt utanför Novus – använder vi en mycket mer typisk miljö som består av webbservrar och olika programservrar. Programnivån kommer inte bara åt Novus för sökning, utan kommer även åt en rad olika saker som inte utgör ämnet för det här dokumentet. Det kan gälla säkerhetsdatabaser, användarinformation, faktureringsdatabaser, MIS-data, dvs allt som ett normalt program behöver.

En stor del av frontend-miljön har virtualiserats med VMware®. De flesta webbservrar och programservrar körs på virtuella maskiner. VMware ger oss möjligheten att utföra samma typ av dynamisk resursallokering i frontend som vi gör i Novus. Vi kan finjustera antalet webbservrar och programservrar för varje program efter behov.

VMware ger oss även drift utan avbrott. VMware HA skyddar mot fel på virtuella maskiner och vMotion™ gör att vi kan utföra underhåll och andra åtgärder utan driftstopp och utan att förlora pågående arbete, vilket vi inte kunde göra tidigare. Innan virtualisering kom och om jag hade 100 användare på en server som behövde underhåll, var jag precis som alla andra tvungen att fasa ut dem, ta dem offline och sedan låta dem logga in igen. Alternativet vore att göra något magiskt med programmering, vilket var nästan helt omöjligt.

Med VMware kan vi utföra underhåll efter behov även mitt på dagen, eftersom vi bara behöver flytta virtuella maskiner till en extrauppsättning av servrar och sedan göra det underhåll vi behöver göra på de ursprungliga servrarna.

Katastrofåterställning
Jag har redan förklarat hur vi erbjuder redundans i ett datacenter, men jag har undvikit att nämna något om katastrofåterställning för att inte försvåra saker och ting. Vid normal drift har vi alltid två datacenter igång med väldigt likartad infrastruktur och identiska data. Om olyckan skulle vara framme och ett av datacentren slutar att fungera, kan det andra datacentret utöka driften för att möta den extra sökbelastningen.

Vi använder replikering för att hålla våra datacenter synkroniserade. Vi har våra egna replikeringsmekanismer som vi har utvecklat för att stödja replikering av våra Novus-index och se till att de är perfekt synkroniserade. Innehållslagren i våra Oracle RAC-databaser replikeras med hjälp av Oracle DataGuard.

NetApp ändrar spelets regler

NetApp-lagring stödjer Novus-arkitekturen (index och Oracle RAC-innehållslager) samt frontend-VMware-miljön. Alla index som hämtas till våra Linux-servrar plus allt innehåll som finns i Oracle RAC lagras i NetApp NAS-lagringssystemet som nås via NFS. Novus skulle helt enkelt inte fungera om vi inte kunde låta tusentals servrar få åtkomst samtidigt till våra lagringssystem med möjligheten att dynamiskt kunna ändra vilka servrar som kommer åt vilken lagring. NetApp-lagring innebar en stor förändring för oss när vi först implementerade det 2002 och det utgör fortfarande den kritiska delen av vår lösning idag.

För att kunna stödja de behov av skalning och prestanda som gäller för WestlawNext har vi nyligen gjort några infrastrukturförbättringar. Vi har lagt till Flash Cache till viktiga NetApp-system. För att vara mer exakt så började vi använda dessa på NetApp-system som erbjuder lagring för ett enstaka Oracle RAC-kluster. Sådana kluster har ofta krav på låg kapacitet och hög prestanda, så Flash Cache hjälper oss att bibehålla hög prestanda utan att behöva lägga till spindlar och slösa kapacitet på att få fram nödvändig prestanda. Vi har även börjat använda Flash Cache på de delade lagringssystem som förser våra Linux-klienter med index och andra data. Baserat på de inledande tester som vi har gjort förväntar vi oss få samma positiva effekt även där.

Som förväntat lägger vi hela tiden till nytt innehåll. Det innebär omindexering och att få ut både det nya innehållet och tillhörande index samtidigt som allt ska fortsätta att vara synkroniserat. Om det uppstår problem och vi behöver backa tillbaka till ett tidigare tillstånd, måste det ske så fort som möjligt. NetApp SnapRestore®-tekniken är den klart bästa lösningen vi har kunnat hitta för att göra detta.

Innan vi gör en inläsning av innehåll skapar vi en Snapshot™-kopia. Om vi senare behöver backa tillbaka av någon anledning, kan vi helt enkelt utföra en SnapRestore för att återställa vårt lager (i ett datacenter och sedan i nästa) till det tillstånd som gällde innan inläsningen gjordes. (I vissa fall måste loggar för databaser tillbakaspelas.)

Vi använder NetApp-deduplicering i vår VMware-miljö för att eliminera dupliceringen som följer med att ha ett stort antal nästan identiska virtuella maskiner. På enbart en avdelning finns det över 9 000 virtuella VMware-maskiner som körs på NetApp-lagringssystemet, och vi har gjort utrymmesbesparingar på över 160 TB i primärt lager genom att tillämpa deduplicering.

För att hantera vår miljö använder vi hela uppsättningen av NetApp OnCommand™-hanteringsprodukter som Operations Manager, Provisioning Manager, Performance Manager och OnCommand Insight. Det här ger oss tillgång till en uppsättning verktyg som fungerar för alla våra NetApp-lagringssystem, vilket förenklar hanteringen, gör att allokering går snabbare och identifierar prestandaproblem. OnCommand Insight (tidigare NetApp SANscreen®) ger oss en konsoliderad översikt över hela vår heterogena lagringsmiljö med information om kapacitet, anslutning, konfigurationer och prestanda. Det varnar även när en komponent inte fungerar, så att vi kan lösa problemet innan redundanta komponenter uppvisar ett fel till.

Gör mer med mindre

Jag nämnde de förbättringar av effektivitet och skalbarhet som vi har åstadkommit genom att implementera WestlawNext och andra tjänster med hjälp av infrastrukturen som jag har beskrivit. Genom att dela infrastrukturen i backend kan vi effektivt möta hög belastning för våra olika program genom att allokera resurser till där de behövs samtidigt som antalet lediga resurser hålls på ett minimum. Virtualisering i frontend har gjort att vi kan minska antalet servrar och annan tillhörande infrastruktur där. Vår totala insats har så här långt gjort att vi inte har behövt bygga ytterligare ett datacenter. NetApp-lagringsteknik, inklusive Snapshot-kopior, SnapRestore, Flash Cache och hela sviten av hanteringsfunktioner hjälper oss att optimera lagringsanvändningen och att få bort flaskhalsar.

För Thomson Reuters är våra relationer med NetApp lika viktiga för vår framgång som NetApp-teknik. Av alla underleverantörer som vi arbetar med är NetApp en av endast två som vi ser som en strategisk teknikpartner. Eventuella problem blir åtgärdade direkt, och NetApp är alltid redo att stödja oss med viktiga teknikinitiativ som WestlawNext. NetApp har arbetat nära oss för att optimera prestanda och för att hjälpa oss att snabbt kunna utnyttja ny lagringsfunktionalitet.

 Har du åsikter om Thomson Reuters fallstudie?

Ställ frågor och utbyt tankar och idéer online i NetApp Communities.

Tech OnTap
Prenumerera nu
Tech OnTap tillhandahåller IT-information varje månad och ger tillgång till praktiska tips och verktyg, intervjuer bakom kulisserna, demos, peer reviews och mycket, mycket mer.

Besök www.netapp.com/us/communities/tech-ontap/ för att prenumerera i dag.