NL2008622A - Gecompartimenteerd computerstelsel. - Google Patents

Gecompartimenteerd computerstelsel. Download PDF

Info

Publication number
NL2008622A
NL2008622A NL2008622A NL2008622A NL2008622A NL 2008622 A NL2008622 A NL 2008622A NL 2008622 A NL2008622 A NL 2008622A NL 2008622 A NL2008622 A NL 2008622A NL 2008622 A NL2008622 A NL 2008622A
Authority
NL
Netherlands
Prior art keywords
end container
compartment
compartments
server
virtual machines
Prior art date
Application number
NL2008622A
Other languages
English (en)
Other versions
NL2008622C2 (nl
Inventor
Willem Abram Reemer
Johan Stephan Belmonte Wanrooy
Guido Vincent Maria Evers
Bart Beemsterboer
Original Assignee
Binck Bank N V
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Binck Bank N V filed Critical Binck Bank N V
Priority to NL2008622A priority Critical patent/NL2008622C2/nl
Application granted granted Critical
Publication of NL2008622C2 publication Critical patent/NL2008622C2/nl
Publication of NL2008622A publication Critical patent/NL2008622A/nl

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5077Logical partitioning of resources; Management or configuration of virtualized resources

Description

Gecompartimenteerd computerstelsel
Stand van de techniek
Figuur 1 toont een computerstelsel 1 dat als voorbeeld van een dergelijk stelsel uit de stand van de techniek kan dienen. Het is gebaseerd op een compartimentering in drie gedeelten: een front-office, een mid-office en een back-office.
De front-office is opgedeeld in twee onderdelen: een eerste front-office 3a voor particuliere gebruikers en een tweede front-office 3b voor professionele gebruikers. De mid-office is ook opgedeeld in twee onderdelen: een eerste mid-office 5a voor particuliere gebruikers en een tweede mid-office 5b voor professionele gebruikers. De back-office tenslotte is eveneens opgedeeld in twee onderdelen: een eerste back-office 7a voor particuliere gebruikers en een tweede back-office 7b voor professionele gebruikers.
De eerste en tweede front-office 3a, 3b bestaan uit een groot aantal webservers en servers voor cliënt applicaties die onder andere vanwege beschikbaarheid en stabiliteit gescheiden zijn van de eerste en tweede mid-office 5a, 5b. Voorbeelden van diensten die de eerste front-office servers ondersteunen zijn: • relatiebeheer KSOD 9 = Klanten Server Orderdesk • Klanten sites 11, die bijvoorbeeld betrekking hebben op Al ex Zelf Beleggen, Alex Fondsbeleggen, Alex Pro (website), Alex Bottomline, Alex Vermogensbeheer,
Al ex Advies, Binck Zelf Beleggen, Binck Pro Trader (website).
• Mobiele sites 13, die bijvoorbeeld betrekking heeft op Alex & Binck: Mobile (voor alle mobiele apparaten).
• Web trader 15: dit betreft bijvoorbeeld Binck Trader, XTA Trader • Trader 17: dit betreft bijvoorbeeld de diensten Alex Pro, Binck Pro Trader • Mobiele applicaties 19, zoals Alex & Binck, dat onder meer geschikt is voor iPhone’s, iPad’s, en systemen gebaseerd op Android,
Voorbeelden van diensten die de tweede front-office servers 3b ondersteunen zijn: Binck België, Binck Frankrijk, Binck Professional, diverse sites mbt derden (BPO’s = Business Process Outsourcing)
In essentie neemt de mid-office 5a functionaliteit voor zijn rekening die gekenmerkt wordt door functies als: instellingen, onderhoud van fondsgegevens, in/uitboeken van portefeuilles, batchprocessen zoals kwartaalnota’s/overzichten, dagelijkse berekeningen van klantrendement, rekeningafschriften, etc. Voorbeelden daarvan zijn basissystemen 21 zoals Stamgegevens (SG) (beursinstellingen, rekeningsoortinstellingen, algemene systeeminstellingen, etc), Fondsgegevens (FG), Risicomanagement-systeem (RMS), Alex Portefeuille Management (APM) (dit is vermogensbeheer), en systemen voor het uitvoeren van bepaalde gedeelde generieke en enkelvoudige functies 23 zoals het verzorgen van informatie betreffende beurskoersen, het aansturen van beursconnecties, etc.
De tweede mid-office 5b verzorgt basissystemen als Binck Alert Module (BAM), handelssysteem/koersverwerking (x-orsyst), etc.
De voornaamste functies van de eerste back-office 7a zijn gekoppeld aan het uitvoeren van batch georiënteerde taken, zoals : (automatische) transactieverwerking, Reconciliatie, Corporate Actions, Settlements, Betalingsverkeer, batchprocessen zoals future bijstelling, renteberekening, assignments en joumalisering. Voor de tweede back-office 7b betreft dat taken als CRM, ordering, Fondsgegevens, Reconciliatie, Corporate Actions, Settlements, Betalingsverkeer.
De back-office 7a, 7b is geïsoleerd van de mid-office 5a, 5b omdat de batch georiënteerde verwerking principieel anders is dan de werking van zowel de front-office 3a, 3b als de mid-office 5a, 5b, die beide voornamelijk real-time functies uitvoeren.
Enkele voordelen van de situatie van figuur 1 zijn: • Eenvoudig beheer (o.a. deployment en management wordt uitgevoerd op diverse servers), • Duidelijk scheidingen, • De batch-gewijze verwerking in de back-office staat los van de real-time verwerking in de front-office en mid-office.
De benodigde capaciteit en schaalbaarheid van front-office 3a, 3b en mid-office 5a, 5b wordt voornamelijk behaald door het bij schakelen van meer (virtuele) machines als dat nodig is. In de praktijk kan dat uitgroeien tot een groot aantal, bijvoorbeeld 200 virtual machines (VM’s) in het mid-office deel 5a, 5b. In een voorbeeld communiceren zij met elkaar op hetzelfde communicatiekanaal. De VM’s zijn bijvoorbeeld van elkaar gescheiden afhankelijk van de functie die ze moeten uitvoeren. Een dergelijke opzet blijkt in de praktijk een onvoorspelbare schaalbaarheid met zich mee te brengen.
Een risico van de huidige opzet ligt in het feit dat met name in het mid-office deel 5a, 5b grote onderlinge afhankelijkheden bestaan waardoor problemen in de mid-office 5a, 5b direct tot grote problemen voor het totale platform kunnen leiden. Om deze risico’s te verkleinen moeten de onderlinge afhankelijkheden omlaag.
Voorts laat de opbouw slecht toe dat er een representatieve testomgeving wordt gebouwd. Daardoor is het platform moeilijk testbaar wat betreft belasting.
Ook is er in de praktijk veel multicast verkeer.
Samenvatting van de uitvinding
Doel van de uitvinding is tenminste één van de hierboven genoemde problemen op te lossen.
Daartoe voorziet de uitvinding in computerstelsel voorzien van meerdere servers, waarbij iedere server is voorzien van een processor die is verbonden met een of meer geheugens waarin een of meer computerprogramma’s zijn opgeslagen die instructies en gegevens omvatten, waarbij de een of meer computerprogramma’s het bedrijf van diverse virtuele machines mogelijk maken, welke virtuele machines als volgt zijn gegroepeerd: a. Een base systeem met meerdere basiscompartimenten, waarbij de virtuele machines in de basiscompartimenten ten minste real-time functionaliteit voor klanten ondersteunen, b. Een generiek systeem met tenminste één generiek compartiment en één batchcompartiment, waarbij de virtuele machines in het generieke compartiment gedeelde functionaliteit ondersteunen voor alle basiscompartimenten en de virtuele machines in het batchcompartiment batchverwerkingsfunctionaliteit betreffende klantgerelateerde batches voor alle basiscompartimenten ondersteunen; c. Een back-office systeem met tenminste één back-office compartiment, waarbij de virtuele machines in het back-office compartiment batchverwerkingsfunctionaliteit betreffende systeem-interne batches voor alle basiscompartimenten ondersteunen; waarbij elk basiscompartiment is onderverdeeld in een front-end container en een backend container, waarbij virtuele machines in de front-end container functionaliteit betreffende direct contact met klanten verschaffen en virtuele machines in de back-end container die niet aan direct klantcontact gekoppelde functionaliteit verschaffen, waarbij alle virtuele machines die bij één front-end container horen op één fysieke front-end container server draaien en waarbij alle virtuele machines die bij één backend container horen op één fysieke back-end container server draaien die gescheiden is van de front-end container server.
Het voordeel van de uitvinding is dat uitval van één machine niet tot uitval (door bijvoorbeeld overload) van andere machines leidt. Voorts leidt een verstoring (bijvoorbeeld op netwerkniveau) binnen een compartiment niet tot een verstoring van het geheel. Ook is het relatief makkelijk een representatieve testomgeving te maken. Als de productieomgeving bijvoorbeeld uit 10 compartimenten zou bestaan op 100.000 klanten, dan kan op de testomgeving 1 compartiment worden ingezet en worden getest met 10.000 (virtuele) klanten.
Figuren
De uitvinding zal worden toegelicht aan de hand van enkele figuren, die zijn bedoeld ter illustratie van een uitvoeringsvorm. Zij zijn niet beperkend bedoeld m.b.t. de uitvindingsgedachte die alleen wordt beperkt door de reikwijdte van de aangehangen conclusies en technische equivalenten daarvan.
Figuur 1 toont een computerstelsel volgens de stand van de techniek.
Figuur 2 toont een gecompartimenteerd computerstelsel volgens de uitvinding.
Figuur 3 toont een overzicht van diverse verkeersstromen.
Figuur 4 toont een host verdeling productie.
Figuur 5 toont een ontwikkelomgeving.
Figuur 6 toont een testomgeving.
Figuur 7 toont een acceptatieomgeving.
Figuur 8 toont een schaduwomgeving.
Beschrijving van uitvoeringsvormen
Figuur 2 toont een gecompartimenteerd stelsel 2 volgens de uitvinding. Dit omvat drie gedeelten: een base systeem 3c, een generiek systeem 5c, respectievelijk een backoffice systeem 7c in plaats van front-office 3a, mid-office 5a, respectievelijk backoffice 7a uit figuur 1.
Het base systeem 3c omvat functionaliteiten die gekoppeld zijn aan basissystemen zoals Stamgegevens (SG), Fondsgegevens (FG), Risicomanagement systeem (RMS),
Alex Portefeuille Management(APM), dat wil zeggen alle real-time functionaliteiten die zich in figuur 1 nog in de mid-office 5a bevonden.
De structuur van het base systeem 3c is, in meer detail, als volgt: • Het base systeem 3c omvat 2 of meer basiscompartimenten 25(n) (n = 1, 2, ..N).
• Elk basiscompartiment 25 (n) heeft een soortgelijke structuur en omvat een deel dat hier front-end container 27(n) (n = 1,2, ..N) wordt genoemd en een tweede deel dat hier back-end container 29(n) (n = 1,2, ..N) wordt genoemd. De front-end onderdelen verzorgen het directe contact met de klant (en/of medewerker).
• Elke front-end container 27(n) omvat: o Relatiebeheer KSOD 9(n) = Klanten Service Orderdesk, o Klanten sites 1 l(n): dit zijn de sites waar retail klanten inloggen en handelen, o Mobiele sites 13(n): dit zijn sites specifiek geschikt voor de mobile device’s (smartphones), o Web trader 15(n): site voor beleggers die frequenter handelen, meer snelheid willen en meer eisen stellen aan de beschikbare financiële analyses e.d., o XTA trader 16(n): deze site is bedoeld voor actieve, semi-professionele beleggers, o Pro Trader 17(n): dit is een separate applicatie die klanten op een PC moeten installeren en waarmee ze (weliswaar via een intemet-connectie, maar niet met een browser) inloggen op een speciale server, o Mobiele applicaties 19(n): dit zijn separate applicaties die op Smartphones en Tablets geïnstalleerd kunnen worden, zodat via een internet-verbinding een directe koppeling met het platform kan worden gelegd.
• Elke back-end container 29(n) omvat basissystemen die niet aan direct klantcontact zijn gekoppeld, zoals de eerder genoemde onderdelen Stamgegevens (SG) (beursinstellingen, rekeningsoortinstellingen, algemene systeeminstellingen, etc), Fondsgegevens (FG), Risicomanagement-systeem (RMS), Alex Portefeuille Management (APM).
Het generieke systeem 5c omvat een generiek compartiment 23 voor generieke, enkelvoudige functies zoals het verzorgen van beurskoersen, beursconnecties, nieuwsfeeds, etc. Ook omvat het generieke systeem 5c een batchcompartiment 31 voor het uitvoeren van batchverwerkende taken zoals: kwartaalnota’s/overzichten, dagelijkse berekening van klantrendement, rekeningafschriften (dus vooral gericht op klantgerelateerde batches). In de regel zal er één generiek compartiment en één batchcompartiment zijn en zullen er meerdere basiscompartimenten zijn. Failover voor generiek en batch is dan binnen het generieke compartiment, respectievelijk het batch compartiment geregeld. In theorie kunnen er meerdere generieke compartimenten en batch compartimenten zijn.
Het back-office systeem 7c kan identiek zijn aan back-office 7a en omvat een back-office compartiment 32 dat is ingericht voor het verwerken van batchgewijze transacties/processen, zoals: future bijstelling, renteberekening, assignments, journalisering (dus meer gericht op interne batches).
Base compartimenten 25(n) hebben een schaling die gekoppeld is aan het aantal klanten. Het generieke compartiment 23 schaalt mee met het aantal ontvangen koersen en aantal aangesloten beurzen.
Hierna zal worden uitgelegd hoe de basiscompartimenten 25(n), het generieke compartiment 23, het batchcompartiment 31 en het back-office compartiment 32 op fysieke computers wordt geïmplementeerd. Naar elk van die computers wordt hierna ook wel verwezen als “server”, “host”, “ESX host” of kortweg “ESX” (ESX is een VMWare product dat de virtualisatie verzorgt. Vanuit VMWare wordt de fysieke machine waar VMs op draaien ESX Hosts genoemd).
Voor alle duidelijkheid wordt hier kort beschreven en getoond hoe zo’n computer er uit kan zien. Zie figuur 8. Figuur 8 toont een computer inrichting 801met een processor/CPU 802 voor het uitvoeren van rekenkundige bewerkingen.
De processor 802 is verbonden met een aantal geheugencomponenten waaronder een harde schijf 805, Read Only Memory (ROM) 807, Electrically Erasable Programmable Read Only Memory (EEPROM) 809 en Random Access Memory (RAM) 811. Niet al deze geheugentypen hoeven noodzakelijkerwijs aanwezig te zijn. Bovendien hoeven zij niet fysiek vlak bij de processor 802 te zijn geplaatst. Zij kunnen ook op afstand daarvan zijn geplaatst.
De processor 802 is eveneens verbonden met middelen voor het invoeren van instructies, gegevens, enz. door een gebruiker, zoals een toetsenbord 813 en een muis 815. Andere invoermiddelen, zoals een touch screen, een track ball en/of spraak converter, die bekend zijn aan de deskundige, kunnen eveneens worden toegepast.
Een met de processor 802 verbonden leeseenheid 817 is voorzien. De leeseenheid 817 is ingericht om gegevens te lezen van en eventueel op te slaan op een gegevensdrager, zoals een floppy disk 819 of een CDROM 821. Andere gegevensdragers kunnen bijvoorbeeld DVD's, Blu Ray disks, Compact Flash (CF), Secure Digital (SD), Micro SD, Mini SD, Extreme Digital (xD), en memory sticks betreffen, zoals bekend is aan de deskundige.
De processor 802 is ook verbonden met een printer 823 voor het printen van uitvoergegevens op papier, alsmede een weergeefeenheid 803, bijvoorbeeld een monitor of LCD (Liquid Crystal Display) scherm, een plasma display panel, een Organic Light Emitting Diode (OLED), een Active Matrix OLED (AMOLED) of enig ander type weergeefeenheid bekend aan de deskundige.
De processor 802 is verbonden met een communicatienetwerk 827, bijvoorbeeld het PSTN (Public Switched Telephone Network), een lokaal netwerk (LAN = local area network), een breedgebied-netwerk (WAN = Wide Area Network), enz. door middel van invoer/uitvoermiddelen 825. De processor 802 is ingericht om met andere communicatie-inrichtingen te communiceren via het netwerk 27. In het geval van de uitvinding kunnen (niet getoonde) computers (bijvoorbeeld pc's, laptops, smartphones, tabloid computers) van gebruikers inloggen op de processor 802 via het netwerk 827. De processor 802 kan zijn geïmplementeerd als een op zich zelf staand systeem of als een aantal parallel opererende processoren, die ieder zijn ingericht om subtaken van een groter programma uit te voeren, of als een of meer hoofdprocessoren met diverse subprocessoren. Gedeelten van de functionaliteit van de uitvinding kunnen zelfs, indien gewenst, worden uitgevoerd door op afstand gelegen processoren die met processor 802 communiceren via netwerk 827.
In overeenstemming met de uitvinding wordt elk basiscompartiment 25(n) gehost op zijn eigen, aparte fysieke servers, zoals aan de hand van figuur 4 nader zal worden toegelicht. Op elke server draaien verschillende VM’s voor de verschillende deelsystemen (bijvoorbeeld 10 tot 20 VM’s per server). Op deze wijze wordt de functionele scheiding gekoppeld aan een technische scheiding.
Gedeelde functionele componenten worden als aparte compartimenten neergezet op eigen servers in generiek systeem 5c (zie figuur 4). Dit betreft bijvoorbeeld het generieke compartiment 23 voor generieke, enkelvoudige functies zoals koersvoorziening en het eerder genoemde batchcompartiment 31 voor b atchverwerkingsfunctie s.
De basiscompartimenten 25(n) omvatten met name die onderdelen die wat betreft schaling een min of meer lineaire relatie hebben met de aantallen klanten. Twee maal zoveel klanten betekent twee maal zoveel basiscompartimenten.
Richtlijnen
Om te voorkomen dat problemen in één basiscompartiment 25(n) tot problemen leiden binnen een ander compartiment 25(i), mogen dergelijke VM’s niet over verschillende compartimenten 25(i) worden heen verplaatst. Bovendien mag een van te voren bepaalde configuratie op een server niet dynamisch worden aangepast zonder menselijke interventie, o.a. ter voorkoming van overbooking. Van overbooking is sprake als men meer virtuele CPU’s zou uitdelen / gebruiken dan er fysieke CPU cores in de fysieke ESX host aanwezig zijn. Als men bijvoorbeeld 20VM’s zou uitdelen die virtueel 2 CPU’s “gebruiken”, zou men 40 virtuele CPU’s hebben. Als men poogt dit te verwezenlijken op een 24 core machine heeft men een overbooking van 16 virtuele CPU’s.
Verdere eisen zijn: • Uitval van een VM in een front-end container 27(n) mag niet tot verstoring leiden, • Uitval van één server mag niet tot grote verstoring leiden Instellingen van compartimenten
Voor het aantal VM’s die draaien in de drie typen compartimenten gelden omwille van de beschikbaarheid in een uitvoeringsvorm bijvoorbeeld de volgende uitgangspunten (zie ook figuur 3): • Elk basiscompartiment 25(n) is dubbel uitgevoerd. Voor elk basiscompartiment 25(n) is er dus een reserve basiscompartiment 25r(n) (niet getekend in figuur 2, wel in figuur 4). Stel dat “M” het aantal VM’s van een front-end container op een server is dat een belasting van een vooraf bepaald aantal calls/uur(client-server sessies) aan kan zonder dat de betreffende server uitvalt of daarop draaiende services uitvallen en de CPU-belasting op de server <= 50% is. Al die M VM’s per front-end moeten dan allemaal volledig op één ESX draaien en niet deels op een andere ESX. Bovendien heeft de identieke reserve front-end container 27r(n) van reserve basiscompartiment 25r(n) dan ook M VM’s draaien op een fysiek aparte reserve ESX. Op deze manier is ook elke ESX simpelweg dubbel uitgevoerd en kan een fysieke uitval van een ESX host worden opgevangen.
• Voor de front-end container 27(n) zijn M VM’s nodig. Dan kan een praktisch systeem bijvoorbeeld 2*M VM’s hebben voor de bijbehorend back-end containers 29(n). Daarvoor zijn dan dubbel zoveel servers ESX nodig. Dit zal verder in detail worden toegelicht onder verwijzing naar figuur 4.
• Het aantal VM’s wordt vastgesteld aan de hand van de verwachte belasting op de verschillende systemen: o Base systeem 3c schaalt mee met het aantal klanten, o Generiek compartiment 23 schaalt mee met het aantal fondsen/koersen, o Batch compartiment 31 schaalt mee met het aantal klanten, maar de relatie zal in de praktijk anders zijn dan die bij base systeem 3c, o Back-office systeem 7c schaalt mee met het aantal klanten. In de praktijk is dat ongeveer op dezelfde wijze als bij batch compartiment 31.
Het aantal VM’s in deze vier systemen kent geen vaste relatie, d.w.z. het aantal wordt per systeem bepaald.
• Een batchcompartiment 31 in generiek systeem 5c heeft (net als de andere “Windows” georiënteerde compartimenten) diverse typen VM’s. Voor het uitvoeren met voldoende capaciteit van een functie kunnen er meerdere, bijvoorbeeld P, VM’s van hetzelfde type nodig zijn om de load van een VM lager dan of gelijk aan 50% te houden. Daarnaast draait er dan één extra VM om uitval tegen te gaan, hetgeen leidt tot een totaal aantal van P+l VM’s. Als voorbeeld: voor een bepaald aantal calls/uur van Type A, zijn 4 VM’s nodig, voor type B 3 VM’s en voor type C 1 VM. Dan zullen er in het batch compartiment 31 voor Type A bijvoorbeeld 5x VM, voor Type B 4x VM en voor Type C 2x VM draaien.
• Al deze P+l VM’s zijn gedurende bedrijf actief en zorgen ervoor dat als er een VM uitvalt de capaciteit nog steeds voldoende is en het systeem niet direct in de gevarenzone komt. Voor de beschikbaarheid is er een reserve server die identiek is geconfigureerd als de andere server, dus inclusief P+l draaiende VM’s.
• Generiek compartiment 23 in generiek systeem 5c heeft Q+l VM’s. Met “Q” VM’s wordt bedoeld het aantal VM’s van generiek compartiment 23 dat een belasting van het vooraf bepaalde aantal calls/uur (client-server sessies) aan kan zonder dat de betreffende server uitvalt of daarop draaiende services uitvallen en de CPU-belasting op de server <= 50% is. Er draait dus voor de beschikbaarheid altijd één VM van generiek compartiment 23 meer dan volgens de verwachting nodig zou zijn. Al deze Q+l VM’s zijn gedurende bedrijf actief en zorgen ervoor dat als er een VM uitvalt de capaciteit nog steeds voldoende is en het systeem niet direct wordt overbelast. Voor de beschikbaarheid is er een reserve server die identiek is geconfigureerd als de andere server, dus inclusief Q+l draaiende VM’s.
• Het back-office compartiment 32 in het back-office systeem 7c is bijvoorbeeld een AIX applicatie en gebruikt dan geen VM’s.
Instellingen van ESX hosts
Tijdens onderzoek naar problemen is gebleken dat overbooking van processoren op een ESX kan leiden tot problemen zoals gemiste of verloren gegane paketten op de virtuele NICS (= Network Interface Cards). Diverse programmatuur heeft hier last van in de praktijk. Een issue is daarbij dat er veel “listeners” (een “listener” luistert al het (netwerk)verkeer af en zoekt verkeer eruit dat voor hem (zijn server) is bestemd) op één ESX host staan die allemaal naar dezelfde multicast boodschappen luisteren. Bij ontvangst van zo’n multicast boodschap worden al deze listeners actief en zij vragen dan dus op hetzelfde moment CPU-tijd. Bij overbooking kan het voorkomen dat listeners enkele clock cycli zullen moeten wachten wat onder meer load retransmits kan veroorzaken. In de productieomgeving is daarom geen overbooking op een ESX toegestaan. Dat wil zeggen, er wordt voor gezorgd, dat bij piekbelasting van alle processen (VM’s) die op een ESX lopen de ESX dit ook daadwerkelijk aan kan. De indeling in VMWare wordt zo gekozen, dat er niet meer virtuele CPU’s worden uitgedeeld dan er fysieke cores (=CPU’s) zijn.
Tijdens onderzoek naar problemen is ook gebleken dat Hyperthreading (een eigenschap van sommige chips waardoor één fysieke CPU naar buiten optreedt als twee logische CPU’s) op een fysiek niveau zou kunnen leiden tot problemen zoals gemiste of verloren gegane pakketten. Het rendement blijkt in de praktijk ook niet zo hoog te zijn. Het rendement weegt hierbij niet op tegen de risico’s. In de productieomgeving zal daarom geen hyperthreading op de ESX worden gebruikt.
Op Network Interface Cards van de ESX’s wordt bij voorkeur “auto negotiate” ingesteld. Daarmee wordt automatisch een actuele conditie herkend en worden instellingen dienovereenkomstig aangepast. In de praktijk betekent dit dat lijnsnelheden aan beide kanten van de Network Interface Cards worden waargenomen en dat dan de hoogst haalbare snelheid wordt gekozen.
Netwerk.
Nu zal het netwerk van het platform in meer detail worden beschreven onder verwijzing naar figuur 3. Figuur 3 toont zowel de verschillende logische componenten van het stelsel 2 als de diverse verkeersstromen daarbinnen.
Het stelsel 2 is via een of meer geschikte firewalls 37 met een al dan niet beveiligd netwerk 827 verbonden, zodat gebruikers met hun eigen computers (bijvoorbeeld pc's, laptops, smartphones, tabloid computers) toegang kunnen krijgen tot het stelsel 2.
De figuur toont twee basiscompartimenten 25(1), 25(2) met hun respectieve reserve basiscompartimenten 25r(l), 25r(2) in gestippelde lijnen in het base systeem 3c, alsmede het generieke compartiment 23 en batchcompartiment 31 in generiek systeem 5c en het back-office compartiment 32.
Elke front-end container 27(n) heeft meerdere VM’s. Een groep VM’s 41(n) is verantwoordelijk voor Klantensites 11 (n), een groep VM’s 43(n) voor Pro Trader 17(n), en verdere groepen VM’s 45(n) voor alle functies die bij de front-end containers 27(n) zijn genoemd (figuur 2).
Elke back-end container 29(n) heeft ook meerdere VM’s. Zo kan een groep VM’s 47(n) verantwoordelijk zijn voor Stamgegevens (SG) (beursinstellingen, rekeningsoort-instellingen, algemene systeeminstellingen, etc), een groep VM’s 49(n) voor Fondsgegevens (FG), en steeds een aparte VM’s 51(n),.....voor andere taken zoals Risicomanagement-systeem (RMS) en Alex Portefeuille Management (APM).
Het generieke compartiment 23 heeft bijvoorbeeld een groep VM’s 53 voor QDS (= Quote Distribution Service), een groep VM’s 55 voor nieuws en verdere groepen VM’s 57 voor overige taken.
Het batch compartiment 31 heeft diverse groepen VM’s 59, 61, 63, .... voor batch-taken als kwartaalnota’s/overzichten, dagelijkse berekening van klantrendement, rekeningafschriften.
Het back-office compartiment 32 werkt niet met VM’s, maar bijvoorbeeld met één softwarepakket.
De netwerkverbindingen binnen het in figuur 3 getoonde stelsel 2 zijn als volgt.
Tussen de firewalls 37 en het stelsel 2 bevinden zich diverse VLAN (= Virtual Local Area Network) verbindingen, die verantwoordelijk zijn voor communicatieverkeer (bijvoorbeeld al het “Windows™” verkeer) bijvoorbeeld middels TCP/IP pakketverkeer (maar elk ander geschikt communicatieprotocol kan in plaats daarvan worden gebruikt). Deze VLAN verbindingen worden hier externe VLAN verbindingen 67(1), 67(2), 67(3) genoemd. Alle VM’s in alle compartimenten kunnen via een van deze externe VLAN verbindingen 67(1), 67(2), 67(3) met de buitenwereld communiceren via de firewalls 37.
Een verdere groep VLAN verbindingen zijn TIBCO VLAN verbindingen 69, waarover TIBCO verkeer, waaronder notifications, heen en weer kan worden gestuurd. TIBCO verkeer verwijst naar Messaging middleware met de productnaam Rendezvous dat verkrijgbaar is bij TIBCO Software Inc., Palo Alto, CA (www.tibco.com) dat betrekking heeft op applicatie integratie producten. Het betreft bijvoorbeeld “request/supply”, publicatie- en abonneemodellen. Deze TIBCO VLAN verbindingen 69 verbinden alle VM’s in alle compartimenten met elkaar zodat iedere VM in elk compartiment boodschappen kan uitwisselen met iedere andere VM in elk (ander) compartiment. Er zijn aparte TIBCO switches. Dit heeft als voordeel dat het TIBCO verkeer niet over de firewalls 37 gerouteerd hoeft te worden en de TIBCO switches worden zo geconfigureerd dat ze alleen TIBCO verkeer doorlaten.
Een speciale groep koersinformatie VLAN verbindingen 71 is aanwezig tussen de VM’s 53 in het generieke compartiment 23 en die VM’s in het batchcompartiment 31, de front-end containers 27(n) en de back-end containers 29(n) die gebruik maken van (actuele) koersinformatie van beurzen over de gehele wereld.
Binnen elk basiscompartiment 27(n) bevindt zich een interne basiscompartiment VLAN verbinding 73(n) voor communicatieverkeer dat alleen tussen VM’s binnen één en hetzelfde basiscompartiment 27(n) wordt verstuurd. Een interne generieke-compartiment VLAN verbinding 74 bevindt zich binnen het generieke compartiment 23 voor communicatieverkeer dat alleen tussen VM’s binnen het generieke compartiment 23 wordt verstuurd. Evenzo is er een interne batchcompartiment VLAN verbinding 75 voor communicatieverkeer dat alleen tussen VM’s binnen het batchcompartiment 31 wordt verstuurd.
Tenslotte is er een container VLAN verbinding 77(n) binnen elke (front-end of backend) container 27(n), 29(n) die alleen zorgt voor een verbinding tussen VM’s binnen één container 27(n), 29(n).
Op deze wijze is er een opdeling in VLAN’s gekozen zodanig dat de interferentie van de diverse TIBCO kanalen zo klein mogelijk wordt gehouden en ervoor wordt gezorgd dat het multicast verkeer een zo klein mogelijk groep servers hoeft te bereiken. Deze indeling houdt ook een zekere functionele scheiding in.
Hardware
Zoals eerder gezegd, wordt uitgegaan van een vooraf bepaald aantal calls/uur (client-server sessies). Daarvoor is een aantal “M” VM’s in een front-end container 27(n) van een basiscompartiment 25(n) nodig. Zoals gezegd, corresponderen M VM’s met een belasting van een server zonder dat de betreffende server uitvalt of daarop draaiende services uitvallen en de CPU-belasting op de server <= 50% is. Daarom is voor die M VM’s in feite een halve server nodig. Die server is in figuur 4 aangeduid met 33(n) en wordt hieronder aangeduid als front-end container server. Voor de beschikbaarheid draaien er M identieke reserve VM’s van een reserve front-end container 27r(n) op een reserve front-end container server 33(n).
Bij deze M VM’s in de front-end container 27(n) horen 2*M VM’s van een back-end container 29(n), die in een aparte back-end container server 35(n) draaien. Voor de beschikbaarheid draaien er 2*M identieke reserve VM’s van een reserve backend container 29(n) op een reserve back-end container server 35(n). tezamen vormen de M VM’s van de front-end container 27(n) en de 2*M VM’s van de back-end container 29(n) één basiscompartiment 25(n). Voor één basiscompartiment is dus de capaciteit van 1,5 server ESX nodig. De halve capaciteit die op front-end container server 33(n) beschikbaar blijft kan op voordelige wijze worden benut voor het laten draaien van M VM’s van een reserve front-end container 27r(n+l) van een ander reserve basiscompartiment 25r(n+l). Dit is weergegeven in figuur 4. Figuur 4 toont ook hoe op dezelfde wijze de halve capaciteit van reserve front-end container server 33(n) gebruikt wordt voor M VM’s die behoren bij front-end container 27(n+l) van basiscompartiment 25(n+l).
Zo wordt steeds de overblijvende halve capaciteit van een eerste front-end container server 33(n) die behoort bij M VM’s van een front-end container 27(n) van een eerste basiscompartiment 25(n) gebruikt voor M VM’s van een reserve front-end container 27r(n+l) van een tweede reserve basiscompartiment 25r(n+l), welke tweede reserve basiscompartiment behoort bij een tweede basiscompartiment 25(n+l).
Evenzo is er een tweede front-end container server 33(n+l) waarop M VM’s draaien van front-end container 27(n+l) van het tweede basiscompartiment 25(n+l), waarvan de overblijvende halve capaciteit als reserve front-end container server 33(n) dient voor de reserve M VM’s van reserve front-end container 27r(n+l) van reserve basiscompartiment 25r(n).
Dit delen van servers ESX om optimaal gebruik te maken van de aanwezige capaciteit van servers ESX kan niet plaatsvinden voor back-end containers. Bij elke back-end container 29(n), 29(n+l) horen steeds 2*M VM’s die de volledige capaciteit van een back-end container server 35(n), 35(n+l) gebruiken. Bijgevolg is er voor elke reserve back-end container 29r(n), 29r(n+l) ook steeds een aparte back-end container server 35(n), 35r(n+l) nodig.
Totaal betekent dit dat er voor twee basiscompartimenten 25(n), 25(n+l) en hun bijbehorende reserve basiscompartimenten 25r(n), 25r(n+l) zes servers 33(n)/33r(n+l), 33(n+l)/33r(n), 35(n), 35(n+l), 35r(n), 35r(n+l) nodig zijn.
Voor generiek compartiment 23 in generiek systeem 5c wordt niet zozeer gewerkt met meerdere servers, mar wordt beschikbaarheid bereikt door een extra VM te definiëren. Zoals uitgelegd zijn er bijvoorbeeld P VM’s van hetzelfde type nodig zijn om de load van een VM lager dan of gelijk aan 50% te houden. Daarnaast draait er dan één extra VM om uitval tegen te gaan, hetgeen leidt tot een totaal aantal van P+l VM’s. Als voorbeeld: voor een bepaald aantal calls/uur van Type A, zijn 4 VM’s nodig, voor type B 3 VM’s en voor type C 1 VM. Dan zullen er in het batch compartiment 31 voor Type A bijvoorbeeld 5x VM, voor Type B 4x VM en voor Type C 2x VM draaien.
Figuur 5 laat zien dat voor het stelsel een eenvoudige ontwikkelomgeving kan worden opgesteld. De totale ontwikkelomgeving omvat bijvoorbeeld diverse individuele ontwikkelomgevingen 01, 02, .... op aparte ontwikkel servers 41(n) voor individuele ontwikkelaars, waarop zich steeds één basiscompartiment 25(n) bevindt en eventueel één batchcompartiment 3 l(n). Er is bovendien een gezamenlijk ontwikkelomgeving 01-05 op een eerste gezamenlijke server 43 die één of meer generieke compartimenten 23(1), 23(2), ... heeft. Bovendien is er een tweede gezamenlijke ontwikkelomgeving 01-05 voor het back-office systeem. In Figuur 5 worden twee “instanties” 32(1), 32(2) van de back-office en twee “instanties” 23(1), 23(2) van generieke compartimenten gezamenlijk gebruikt door de 01-05 omgevingen. Per ontwikkelomgeving kan de ontwikkelaar er voor kiezen om aan instantie 23(1) of 23(2) en aan instantie 32(1) of 32(2) gekoppeld te worden. Op deze manier is het niet noodzakelijk dat er 5 back-office en 5 generieke compartimenten gerealiseerd worden.
Het blok 40 betekent hier dat de twee backoffices 3291), 32(2) en diverse Databases op één fysieke server kunnen draaien.
Figuur 6 toont een voorbeeld van de testomgeving. Deze omvat dezelfde testservers als de ontwikkel servers 41(n), die onderdeel uitmaken van een testomgeving waarin zich ook steeds een back-office 32(n) bevindt. Daartoe zijn er dan evenzo vele instanties 32(n) van de back-office als er base compartimenten 25(n) zijn. Deze instanties van de back-office 32(n) draaien allen op dezelfde server 40. De gezamenlijke server 43 uit de ontwikkelomgeving van figuur 5 kan ook in de testomgeving worden gebruikt t.b.v. instanties 23(1), 23(2) van generieke compartimenten.
Figuur 7 toont een acceptatieomgeving. De ontwikkel/testservers 41(n) kunnen weer worden gebruikt, waarbij de batchcompartimenten 3 l(n) zijn verwijderd. In plaats daarvan wordt batchcompartiment 31 op één batchserver 42 geplaatst. Generiek compartiment 23 bevindt zich op server 43, terwijl back-office 32 zich met enkele databases op server 40 bevindt.

Claims (10)

1. Computerstelsel (2) voorzien van meerdere servers, waarbij iedere server is voorzien van een processor (801) die is verbonden met een of meer geheugens (805 -811) waarin een of meer computerprogramma’s zijn opgeslagen die instructies en gegevens omvatten, waarbij de een of meer computerprogramma’s het bedrijf van diverse virtuele machines mogelijk maken, welke virtuele machines als volgt zijn gegroepeerd: a. Een base systeem (3c) met meerdere basiscompartimenten (25(n), waarbij de virtuele machines in de basiscompartimenten (25(n) ten minste real-time functionaliteit voor klanten ondersteunen, b. Een generiek systeem (5c) met tenminste één generiek compartiment (23) en één batchcompartiment (31), waarbij de virtuele machines in het generieke compartiment (23) gedeelde functionaliteit ondersteunen voor alle basiscompartimenten (25(n)) en de virtuele machines in het batchcompartiment (31) batchverwerkingsfunctionaliteit betreffende klantgerelateerde batches voor alle basiscompartimenten (25(n)) ondersteunen; c. Een back-office systeem (7c) met tenminste één back-office compartiment (32), waarbij de virtuele machines in het back-office compartiment (32) batchverwerkingsfunctionaliteit betreffende systeem-interne batches voor alle basiscompartimenten (25(n)) ondersteunen; waarbij elk basiscompartiment (25(n)) is onderverdeeld in een front-end container (27(n)) en een back-end container (29(n), waarbij virtuele machines in de front-end container (27(n)) functionaliteit betreffende direct contact met klanten verschaffen en virtuele machines in de back-end container (29(n)) die niet aan direct klantcontact gekoppelde functionaliteit verschaffen, waarbij alle virtuele machines die bij één front-end container (27(n)) horen op één fysieke front-end container server (33(n)) draaien en waarbij alle virtuele machines die bij één back-end container (29(n)) horen op één fysieke back-end container server (35(n)) draaien die gescheiden is van de front-end container server (33(n)).
2. Computer stelsel volgens conclusie 1, met het kenmerk dat de een of meer computerprogramma’s het bedrijf van diverse reserve virtuele machines mogelijk maken, die tenminste voor elk basiscompartiment (25(n)) een reserve basiscompartiment (25r(n)) met een reserve front-end container (27r(n)) en een reserve back-end container (29r(n)) definiëren, zodanig dat reserve virtuele machines voor een reserve front-end container (27r(n)) op één fysieke reserve front-end container server (33r(n)) draaien en waarbij alle reserve virtuele machines die bij één reserve back-end container (29r(n)) horen op één fysieke reserve back-end container server (35r(n)) draaien die gescheiden is van de reserve front-end container server (33r(n)).
3. Computer stelsel volgens conclusie 2, met het kenmerk, dat alle virtuele machines die bij een eerste front-end container (27(n)) horen op een eerste fysieke front-end container server (33(n)) draaien, alle virtuele machines die bij een eerste bijbehorende back-end container (29(n)) horen op een eerste fysieke back-end container server (3 5(n)) draaien die gescheiden is van de eerste front-end container server (33(n)), alle reserve virtuele machines voor een eerste reserve front-end container (27r(n)) die behoort bij de eerste front-end container (27(n)) op een eerste reserve front-end container server (33r(n)) draaien, alle reserve virtuele machines voor een eerste reserve back-end container (29r(n)) op eerste reserve back-end container server (35r(n)) draaien die gescheiden is van de eerste reserve front-end container server (33r(n)), en alle virtuele machines die bij een tweede front-end container (27(n+l)) horen op een tweede fysieke front-end container server (33(n+l)) draaien, alle virtuele machines die bij een tweede bijbehorende back-end container (29(n+l)) horen op een tweede fysieke back-end container server (35(n+l)) draaien die gescheiden is van de tweede front-end container server (33(n+1)), alle reserve virtuele machines voor een tweede reserve front-end container (27r(n+l)) die behoort bij de tweede front-end container (27(n+l)) op een tweede reserve front-end container server (33r(n+l)) draaien, alle reserve virtuele machines voor een tweede reserve back-end container (29r(n+l)) op tweede reserve back-end container server (35r(n+l)) draaien die gescheiden is van de tweede reserve front-end container server (33r(n+l)), en dat de eerste fysieke front-end container server (33(n)) dezelfde is als de tweede reserve front-end container server (33r(n+l)) en de eerste reserve front-end container server (33r(n)) dezelfde is als de tweede front-end container server (33(n+l)).
4. Computer stelsel volgens conclusie 1 met het kenmerk, dat het een of meer met een openbaar netwerk (827) verbonden firewalls (37) omvat, die zijn aangesloten op alle basiscompartimenten (25(n)), alle generieke compartimenten (23), alle batchcompartimenten (31) en alle back-office compartimenten (32).
5. Computer stelsel volgens conclusie 2 of 3, met het kenmerk, dat het een of meer met een openbaar netwerk (827) verbonden firewalls (37) omvat, die zijn aangesloten op alle basiscompartimenten (25(n)), alle reserve basiscompartimenten (25r(n)), alle generieke compartimenten (23), alle batchcompartimenten (31) en alle back-office compartimenten (32).
6. Computer stelsel volgens een van de voorgaande conclusies, met het kenmerk, dat het een apart eerste Virtual Local Area Netwerk (69) omvat tussen alle basiscompartimenten (25(n)), alle generieke compartimenten (23), alle batchcompartimenten (31) en alle back-office compartimenten (32) dat alleen wordt gebruikt voor TIBCO verkeer.
7. Computerstelsel volgens een van de voorgaande conclusies, met het kenmerk, dat het een apart tweede Virtual Local Area Netwerk (71) omvat tussen alle basiscompartimenten (25(n)), alle generieke compartimenten (23) en alle batchcompartimenten (31) dat uitsluitend wordt gebruikt voor verkeer met betrekking tot aandelenkoersen.
8. Computerstelsel volgens een van de voorgaande conclusies, met het kenmerk, dat het voor elk basiscompartiment (25(n)) een apart derde Virtual Local Area Netwerk (73(n)) omvat tussen de front-end container (27(n)) en de back-end container (29(n)) dat uitsluitend wordt gebruikt voor TIBCO verkeer tussen de front-end container (27(n)) en de back-end container (29(n)).
9. Computer stelsel volgens een van de voorgaande conclusies, met het kenmerk, dat het voor elk generiek compartiment (23) een apart vierde Virtual Local Area Netwerk (74) omvat dat uitsluitend wordt gebruikt voor TIBCO verkeer binnen het generieke compartiment (23) en voor elk batchcompartiment (31) een apart vijfde Virtual Local Area Netwerk (75) dat uitsluitend wordt gebruikt voor TIBCO verkeer binnen het batchcompartiment (31).
10. Computerstelsel volgens een van de voorgaande conclusies, met het kenmerk, dat het voor elke front-end container (27(n)), respectievelijk elke back-end container (29(n)) een apart zesde Virtual Local Area Network (77(n)) omvat dat uitsluitend wordt gebruikt voor verkeer dat binnen de respectieve container blijft.
NL2008622A 2012-04-11 2012-04-11 Gecompartimenteerd computerstelsel. NL2008622C2 (nl)

Priority Applications (1)

Application Number Priority Date Filing Date Title
NL2008622A NL2008622C2 (nl) 2012-04-11 2012-04-11 Gecompartimenteerd computerstelsel.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NL2008622 2012-04-11
NL2008622A NL2008622C2 (nl) 2012-04-11 2012-04-11 Gecompartimenteerd computerstelsel.

Publications (2)

Publication Number Publication Date
NL2008622C2 NL2008622C2 (nl) 2013-03-25
NL2008622A true NL2008622A (nl) 2013-03-25

Family

ID=46147647

Family Applications (1)

Application Number Title Priority Date Filing Date
NL2008622A NL2008622C2 (nl) 2012-04-11 2012-04-11 Gecompartimenteerd computerstelsel.

Country Status (1)

Country Link
NL (1) NL2008622C2 (nl)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090070771A1 (en) * 2007-08-31 2009-03-12 Tom Silangan Yuyitung Method and system for evaluating virtualized environments
US20100107162A1 (en) * 2008-03-07 2010-04-29 Aled Edwards Routing across a virtual network
US7802000B1 (en) * 2005-08-01 2010-09-21 Vmware Virtual network in server farm

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7802000B1 (en) * 2005-08-01 2010-09-21 Vmware Virtual network in server farm
US20090070771A1 (en) * 2007-08-31 2009-03-12 Tom Silangan Yuyitung Method and system for evaluating virtualized environments
US20100107162A1 (en) * 2008-03-07 2010-04-29 Aled Edwards Routing across a virtual network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANDREW HILLIER: "Transformational analytics:virtualizing IT environments", 1 April 2008, CIRBA WHITE PAPER,, PAGE(S) 1 - 43, XP008135210 *

Also Published As

Publication number Publication date
NL2008622C2 (nl) 2013-03-25

Similar Documents

Publication Publication Date Title
US10699230B2 (en) Order optimization in hybrid cloud networks
US8719131B1 (en) Allocating financial risk and reward in a multi-tenant environment
US20160210700A1 (en) Systems and methods for daily recommended spend
US20160078559A1 (en) Systems and methods for household cash management system
CN102917018A (zh) 端点的负载平衡
US20160005128A1 (en) Systems and methods of applying high performance computational techniques to analysis and execution of financial strategies
AU2007213901A1 (en) Application software initiated speedup
AU2011344038A1 (en) Hybrid cloud broker
CA2806725C (en) Integrating payment aggregators with e-commerce platform
Gundu et al. Hybrid IT and multi cloud an emerging trend and improved performance in cloud computing
US11770342B2 (en) Methods and systems for gateway load balancing
NL2008622C2 (nl) Gecompartimenteerd computerstelsel.
US8856376B1 (en) Stabilization tool for a high-capacity network infrastructure
US10007559B1 (en) Virtual tiering
Shi et al. Hpks: High performance kubernetes scheduling for dynamic blockchain workloads in cloud computing
JP4113253B1 (ja) 証拠金取引会社システム、コンピュータプログラム及び記憶媒体
JP2006338562A (ja) 金融商品管理システム及び金融商品管理方法
CN115619486A (zh) 订单处理方法、装置、电子设备和存储介质
US10387853B1 (en) Secondary purchase card for financial transactions (“cap card”)
Chinyere et al. ADOPTION OF CLOUD COMPUTING AND SERVICE DELIVERY OF COMMERCIAL BANKS IN RIVERS STATE.
CA3166447A1 (en) Method and system for user account initiation and reconciliation
Akinyede Proposed E-Commerce Framework Using Cloud Computing Technology”
CA2995869C (en) Information processing method, server, terminal device, and online transaction method
US20230297413A1 (en) Dual stage bulkheads
Lin et al. Service component architecture for vending machine system in cloud computing infrastructure

Legal Events

Date Code Title Description
MM Lapsed because of non-payment of the annual fee

Effective date: 20230501