Bij de overgang naar een nieuwe versie van een erp-pakket speelt is opslag een belangrijke item. Een san (‘storag area network’) biedt volgens H.S Groenewoud veel voordelen. Hij beschrijft met welke technische aspecten je vervolgens rekening moet houden.
Na het lezen van het interview met Janpieter Scheerder (Computable, 5 januari) en vervolgens het artikel ‘Moeder aller netwerken’ (Computable, 21 januari) wil ik enkele kanttekeningen plaatsen, omdat de belangrijkste aspecten van opslagconcepten zoals san en nas niet aan de orde kwamen.
Stel een bedrijf heeft een erp-pakket, bijvoorbeeld SAP versie 3.x, en het wil naar een volgende versie, bijvoorbeeld 4.6C. Indien het een euroconversie wil kunnen uitvoeren binnen een aanvaardbare tijdslimiet, dan moet het archiveren.
Als besturingssysteem draait Windows NT. In verband met de beschikbaarheid moet het een nspf-systeem (‘no single point of failure’) worden.
De volgende punten moeten dan worden overwogen. Bij onderstaande beschouwing kijk ik alleen naar systeemtechnische zaken; de consequenties voor de organisatie laat ik buiten beschouwing.
1. Is de capaciteit van de huidige infrastructuur toereikend?
2. Zijn de bestaande werkplekken nog bruikbaar, voor wat betreft de hardware?
3. Is de huidige (cpu)servercapaciteit voldoende?
4. Ga je over op Windows 2000?
5. Hoe ga je de ‘failover’ en ‘recovery’ inrichten?
6. Is de huidige opslagcapaciteit voldoende, en indien dat niet het geval is, kun je dan de huidige capaciteit vergroten?
7. Is de combinatie van bovenstaande punten te realiseren binnen het budget en is hiermee een acceptabele responstijd te verkrijgen?
8. Hoe en waarmee ga je archiveren, en moet dit archief online beschikbaar zijn?
9. Hoe wordt de back-up verzorg?
10. Wat zijn de kosten en inspanningen voor het inrichten en het beheer van het gekozen concept?
Nadelen
De eerste drie punten zijn simpel te bepalen. Over punt 4 moet je heel goed nadenken.
Bij punt 5 tot en met 10 is opslag een essentieel punt.
Volgens het principe ‘oude schoenen/nieuwe schoenen’ kun je kiezen voor bestaande oplossingen. Er is dan een paar voor de hand liggende mogelijkheden, elk met zijn eigen voor- en nadelen.
- De SCSI-switch. Lekker simpel en het werkt.
- Een product als Lifekeeper. Een mooie grafische interface en flexibel te gebruiken.
- Microsoft Cluster Server.
De nadelen zijn groot. Voor elke oplossing geldt de beperking van SCSI (maximaal vijftien ID’s) en bossen kabels. In een cluster met alleen Raid-1, ben je gauw door je beschikbare schijven heen. Je mag bovendien slechts één partitie maken op de raid, omdat de koppeling ligt op naar de stationsaanduiding/raid.
Het ‘locken’ van de schijven brengt gevaren met zich mee. Probeer de configuratie maar eens te wijzigen, en zet dan een van de servers uit. Schaalbaarheid moet je zoeken in het bijplaatsen van twee controllers en een nieuwe schijvenkast.
Een ander groot nadeel bij de laatste twee oplossingen is het toenemen van de complexiteit van het SAP-netwerk. Denk hierbij aan de grote hoeveelheid virtuele IP-adressen die nodig zijn om het systeem in de lucht te krijgen. Als je Wins gebruikt voor de naamresolutie, weet je waar ik het over heb. Het extra werk en de kans op ‘uitdagingen’ van een upgrade van de database of – nog erger – van een versie, laten we hier buiten beschouwing.
SAN
Een andere oplossing is een san. Dit is een compleet ander concept, en heeft niet de bovenstaande nadelen. De mogelijkheden zijn eindeloos.
Een san heeft geen problemen in een heterogene omgeving van bijvoorbeeld NT en Unix.
Men kan zelfs dezelfde data delen! Het enige voorbehoud in bovenstaand verhaal is dat de pc voor san-beheer onder NT moet draaien.
Je kunt heel simpel een ‘no single point of failure’-systeem bouwen. Reken maar eens uit hoeveel fysieke verbindingen je kwijt bent (SCSI ten opzichte van FC). Ik heb het dan over ‘alles dubbel’, ook de fibre-kaarten. Deze kun je ook tegelijk gebruiken zodat je een maximale bandbreedte van 200 MB (2 x 100 MB) per server kunt halen (in theorie, omdat er geen PCI bus is die dit aankan, maar toch…).
Kies je voor san, dan word je geconfronteerd met de volgende vragen.
Is het san hardwareonafhankelijk, kun je zelf de componenten uitzoeken?
Welk (fibre)protocol: Point to Point, FC-Al of Fabric, en waarom?
Welke switch(es)? Dit is erg belangrijk. Denk hierbij er ook aan welke protocollen de switch ondersteunt. Er is mooie beheersoftware (Java) en er zijn goed werkende switches, maar helaas niet in combinatie.
Welke Fibre-kaarten in de servers? Dit is minstens zo belangrijk.
Hoeveel opslag is nodig? Indien dat bekend is, kun je de gewenste raids kwijt op het disk-array. Zo niet, is het dan mogelijk om simpel te cascaderen zonder extra controllers. De raid-beheersoftware moet ook gebruikersvriendelijk zijn – gelukkig is dergelijke software op de markt.
Voordat je ook maar een raid kunt gaan bouwen, moet je eerst het een en ander over de database weten die erop gezet word. Anders loopt het voor geen meter.
Hoeveel raid-sets moet je vervolgens minimaal bouwen en met wat voor een soort configuratieprofiel?
Hoe beheer je het san? Hoe zorg je ervoor dat NT niet alle schijven ‘dubbel’ ziet en hoe regel je de ‘locking’ van deze raid-sets. Met een aangepaste disk-driver en ‘lun-masking’ kom je een heel eind.
Kun je ‘online’ raid-sets toevoegen en meteen gebruiken? (NT ziet alleen bij het booten het -vrijgegeven – stuk van een san als lokale schijven.
Hoe houd je de relatie in de gaten van schijven onder NT en raid-sets, op je san-beheer? (Wel eens de verkeerde raid-set gewist ?)
Hoe en waarmee regel je de back-up van het san? Hiervoor bestaan diverse oplossingen. Als je in het achterhoofd houdt dat je geen DLT’s (Digital Linear Tape) per server meer nodig hebt, vallen de kosten wel mee; bovendien maak je er vrienden voor het leven mee bij de afdeling beheer.
Kan het SAP-netwerkdomeinsegment (afhankelijk van de configuratie) de toegenomen capaciteit wel verwerken? De communicatie tussen de database en de rest van je SAP-systeem (TCP/IP) gaat wel degelijk over het netwerk. Het archief kan op het san geplaatst worden, wat de kosten van het archiveringsbudget toch leuk drukt, en prestatietechnisch is het absoluut de best denkbare oplossing.
Hoe gaat de ‘fail-over’ in z’n werk. Conceptueel is het simpel, denk maar aan de SCSI-switch, of aan Life Keeper die het helemaal automatisch kan doen. Technisch gezien is er wel een paar haken en ogen.
Herstel na een ongeval (‘disaster recovery’) krijgt nu opeens een heel invalshoek – dit kun je zelf invullen.
Tot slot een vraag aan de verkoopafdeling. Is er een referentie voor een dergelijk systeem, en zo ja, kun je dan een keer gaan kijken? Dit onder het motto: zien is geloven. Je zult dan vaak zien dat het ineens geen san is, maar een sas (‘san attached storage’).
NAS
Voordat überhaupt ook maar een onderbouwd advies is te geven – en dat is tevens het lastige van bovenstaande verhaal – moet je zelf de benodigde componenten samenstellen en testen. Als je een san wilt bouwen, die je gebruikt als file-server voor bijvoorbeeld ‘streaming video’, ben je gauw klaar. Maar voor een erp-systeem liggen de zaken complexer.
Je kunt niet simpelweg een san kopen en hopen dat alles goed komt. Je moet het hele plaatje bekijken.
In dit verhaal heb ik EMC buiten beschouwing gelaten. Als consultant heb ik er geen ervaring mee, omdat het budgettair niet haalbaar is voor veel klanten.
Afsluitend een opmerking over nas (‘network attached storage’). De elementaire vraag is: wanneer gebruik je die. Ik adviseer een nas als er op een vestiging of afdeling behoefte is aan opslag, voor data die je niet over een altijd-te-krappe huurlijn of netwerk wilt sturen. Het mooie van een nas is dat deze z’n eigen besturingssysteem heeft, waarvoor je dus geen licentie hoeft te betalen. Dit is wel het geval wanneer je een (NT-)server plaatst.
Het beheer van een nas kan gewoon centraal plaatsvinden. Kortom: opslag op verzoek, waar je maar wilt. Heb je heel veel opslagcapaciteit nodig, dan kun je gewoon een tweede san bouwen op locatie, die je ook weer centraal kunt beheren.
Er zijn verschillende sites op internet, waar uitvoerig op de verschillende concepten wordt ingegaan, ook voor niet technisch geschoolde mensen.
Zijn er lezers die een erp-systeem hebben draaien op een ‘echt’ san, dan zou ik daar graag meer over willen weten.
H.S. Groenewoud System Consultant Eberson Consultancy
