Visualisatie van een serverpark en applicaties

[Yelti]

Ik hoop dat ik in het juiste subforum zit.

Ons serverpark bestaat ongeveer uit een 150-tal virtuele machines die draaien op ESX4.1
Dit serverpark is door de jaren heen sterk gegroeid, echter de documentatie niet.
Aangezien we binnenkort overstappen naar een nieuw hardware platform moeten we een en ander in kaart brengen.
Om de downtime in kaart te brengen moeten we bepalen welke machines we samen kunnen migreren(liefst de servers per applicatie die we aanbieden).
Hier wringt het schoentje wan we hebben geen duidelijk overzicht van onze infrastructuur.

Ik ben dus op zoek naar een tool waarmee onze infrastructuur kunnen inventariseren(handmatig is ook ok), maar ik zou deze ook graag willen visualiseren.
Op deze manier hoop ik visueel te kunnen bepalen welke servers een applicatie omvat.
Omgekeerd zou ik graag willen zien hoe de servers aan elkaar gerelateerd zijn.

Vmware zou een tool hebben die dit doet: Virtual Infrastructure navigator, maar deze werkt enkel op vmware met vcenter 5.5.
Bijkomende info:

Oud systeem:
ESX4.1 met IBM San Volume Controller voor de storage.
Voor os werken we met vmdk, voor data met RDM.

Nieuw systeem:
ESX5.5 met IBM storwize storage systeem.
Het is de bedoeling van zo goed als alle RDM's om te zetten naar vmdk's.

We zitten enerzijds met downtime vanwege de conversie van RDM's naar vmdk's en anderzijds de verschillende herstarts bij de installatie van vmware tools en hardware upgrades.

Op applicatie niveau zijn we zo goed als niet ontdubbeld.

Iedere server die down gaat heeft dus een bepaalde impact op onze omgeving en dus onze operaties.

Iemand een idee of ervaringen met bepaalde toos?

[ Voor 22% gewijzigd door Yelti op 18-03-2014 10:05 ]

[redfoxert]

Wij zijn naadloos, zonder downtime of verstoringen, gemigreerd van vSphere 4.1 naar 5.1 (en binnenkort naar 5.5), ruim 1000 VM's in een week.

Waarom denk je dat dat bij jullie niet kan?

[Yelti]

redfoxert schreef op dinsdag 18 maart 2014 @ 09:50:
Wij zijn naadloos, zonder downtime of verstoringen, gemigreerd van vSphere 4.1 naar 5.1 (en binnenkort naar 5.5), ruim 1000 VM's in een week.

Waarom denk je dat dat bij jullie niet kan?

Hmz, misschien nog wat details vergeten.
Oud systeem:
ESX4.1 met IBM San Volume Controller voor de storage.
Voor os werken we met vmdk, voor data met RDM.

Nieuw systeem:
ESX5.5 met IBM storwize storage systeem.
Het is de bedoeling van zo goed als alle RDM's om te zetten naar vmdk's.

We zitten enerzijds met downtime vanwege de conversie van RDM's naar vmdk's en anderzijds de verschillende herstarts bij de installatie van vmware tools en hardware upgrades.

Op applicatie niveau zijn we zo goed als niet ontdubbeld.

Iedere server die down gaat heeft dus een bepaalde impact op onze omgeving en dus onze operaties.
Dat wil ik graag in kaart brengen.

[Equator]

redfoxert schreef op dinsdag 18 maart 2014 @ 09:50:
Wij zijn naadloos, zonder downtime of verstoringen, gemigreerd van vSphere 4.1 naar 5.1 (en binnenkort naar 5.5), ruim 1000 VM's in een week.

Waarom denk je dat dat bij jullie niet kan?

Dat iets technisch in jouw ogen niet direct een probleem is, houdt niet in dat het niet wijs is het e.e.a. in kaart te brengen

[redfoxert]

Equator schreef op dinsdag 18 maart 2014 @ 11:36:
[...]

Dat iets technisch in jouw ogen niet direct een probleem is, houdt niet in dat het niet wijs is het e.e.a. in kaart te brengen

Tuurlijk, dat is het zeker Maar ik vroeg me gewoon af waarom het niet mogelijk zou zijn. Vanwege RDM's dus (sowieso nogal lelijk als je het mij vraagt).

@OP: Zijn er geen andere manieren te verzinnen om deze migratie "live" uit te voeren? Dan is de druk van het in kaart brengen van je service mappings wat minder en kan je toch je migratie deadline halen

[paulhekje]

ik adviseer je bij het in kaart brengen van applicaties de ketens te volgen. Je begint bij de databases/datashares en vandaaruit kijk je welke server/clientapp er gebruik van maakt.
Van elke database/applicatie maak je dan max 1 A4 met de betrokken servers, protocollen en client app.
Daarna kan je pas goed de impact van downtime inschatten.
Zo'n grondige inventarisatie kan je een paar weken tot een paar maanden kosten, afhankelijk van de complexiteit en de achtergrondkennis van wie het gaat doen.
Veelal is dit "handwerk" en een kwestie van overal op inloggen en goed rondneuzen.

Een andere methode is in overleg met de business te bepalen wat echt bedrijfskritisch is en die alleen in kaart te brengen. De rest is dan een gok...

[Yelti]

redfoxert schreef op dinsdag 18 maart 2014 @ 23:17:
[...]


Tuurlijk, dat is het zeker Maar ik vroeg me gewoon af waarom het niet mogelijk zou zijn. Vanwege RDM's dus (sowieso nogal lelijk als je het mij vraagt).

@OP: Zijn er geen andere manieren te verzinnen om deze migratie "live" uit te voeren? Dan is de druk van het in kaart brengen van je service mappings wat minder en kan je toch je migratie deadline halen

Het zijn idd de RDM's die ons de nek om doen.
Dit was vroeger een bewuste keuze die ons de nodige flexibliteit bood, maar nu is de trend om meer naar vmdk's te gaan(oa backup en zo).

Het is niet zo dat al onze servers rdm's bevatten, dus een groot deel kan wel live overgeplaatst worden.
Maar uiteindelijk moeten alle machines 2-3 keer herstart worden en waardoor we toch alles in kaart moeten brengen.

[Yelti]

paulhekje schreef op woensdag 19 maart 2014 @ 07:46:
ik adviseer je bij het in kaart brengen van applicaties de ketens te volgen. Je begint bij de databases/datashares en vandaaruit kijk je welke server/clientapp er gebruik van maakt.
Van elke database/applicatie maak je dan max 1 A4 met de betrokken servers, protocollen en client app.
Daarna kan je pas goed de impact van downtime inschatten.
Zo'n grondige inventarisatie kan je een paar weken tot een paar maanden kosten, afhankelijk van de complexiteit en de achtergrondkennis van wie het gaat doen.
Veelal is dit "handwerk" en een kwestie van overal op inloggen en goed rondneuzen.

Een andere methode is in overleg met de business te bepalen wat echt bedrijfskritisch is en die alleen in kaart te brengen. De rest is dan een gok...

Bedankt voor de tip van het A4'tje, is iets wat ik zeker ga meenemen.
Maar het blijft handig om iets database achtigs te hebben om daar later nog iets mee te kunnen doen.

[Craven]

paulhekje schreef op woensdag 19 maart 2014 @ 07:46:
ik adviseer je bij het in kaart brengen van applicaties de ketens te volgen. Je begint bij de databases/datashares en vandaaruit kijk je welke server/clientapp er gebruik van maakt.
Van elke database/applicatie maak je dan max 1 A4 met de betrokken servers, protocollen en client app.
Daarna kan je pas goed de impact van downtime inschatten.
Zo'n grondige inventarisatie kan je een paar weken tot een paar maanden kosten, afhankelijk van de complexiteit en de achtergrondkennis van wie het gaat doen.
Veelal is dit "handwerk" en een kwestie van overal op inloggen en goed rondneuzen.

Een andere methode is in overleg met de business te bepalen wat echt bedrijfskritisch is en die alleen in kaart te brengen. De rest is dan een gok...

Ik zou eerlijk gezegd precies andersom werken. Je wilt weten wat de downtime is vanuit user perspectief. Niet vanuit IT/backend perspectief. Wat bedoel je precies met niet ontdubbeld? Weet je wel of er servers zijn die dubbel werk doen? Host DBSRV1 db's voor zowel app1 als app2 of is alles neergezet met 1 nut?

Je wilt een overzicht wat je het volgende verteld:
App1 --- DBSRV1
------------DBSRV2
------------WEBSRV1

Maar dan wil je per server eigenlijk ook nog wat paulhekje voorsteld. Je wilt app1 kunnen migreren met alle gerelateerde servers. Maar je wilt vervolgens ook andersom kunnen checken of de servers die je gaat migreren nog ergens anders voor ingezet worden.

[Yelti]

Craven schreef op woensdag 19 maart 2014 @ 09:54:
[...]

Ik zou eerlijk gezegd precies andersom werken. Je wilt weten wat de downtime is vanuit user perspectief. Niet vanuit IT/backend perspectief. Wat bedoel je precies met niet ontdubbeld? Weet je wel of er servers zijn die dubbel werk doen? Host DBSRV1 db's voor zowel app1 als app2 of is alles neergezet met 1 nut?

Je wilt een overzicht wat je het volgende verteld:
App1 --- DBSRV1
------------DBSRV2
------------WEBSRV1

Maar dan wil je per server eigenlijk ook nog wat paulhekje voorsteld. Je wilt app1 kunnen migreren met alle gerelateerde servers. Maar je wilt vervolgens ook andersom kunnen checken of de servers die je gaat migreren nog ergens anders voor ingezet worden.

Exact wat ik bedoel.
Met niet ontdubbeld bedoel ik het volgende:
Geen clustering, failover of standby, ...

[pablo_p]

Ik denk dat het niet zo handig is daar de term "niet ontdubbeld" voor te gebruiken, dat veroorzaakt veel verwarring. Je gebruikt een dubbele ontkenning (niet en ont-), waarmee normaal gesproken weer het origineel bedoeld wordt. Vergelijk: hij werd niet ontmaskerd. Dat betekent dat die persoon wel 'gemaskerd' bleef.

Handiger is te zeggen: er is geen redundancy aanwezig binnen de omgeving.

Ontdubbelen ken ik vooral als term in data-opslag, waar je wilt voorkomen dat dezelfde dat meerdere keren wordt opgeslagen (2 of meer). De meeste oplossing slaan de data dan 1 keer op en gebruiken daarna verwijzingen.

[ Voor 22% gewijzigd door pablo_p op 19-03-2014 15:39 . Reden: Toevoegen betekenig ontdubbelen in data-opslag ]

[Craven]

Yelti schreef op woensdag 19 maart 2014 @ 14:12:
[...]

Exact wat ik bedoel.
Met niet ontdubbeld bedoel ik het volgende:
Geen clustering, failover of standby, ...

Je zou zoiets in een access database kunnen bouwen. Je wilt simpele relaties leggen en de relaties naar voren kunnen brengen. Ik kan zo niks anders bedenken waar dat mee kan maar er zijn vast legio oplossingen.

[Brahiewahiewa]

Craven schreef op zondag 23 maart 2014 @ 21:53:
[...]Je zou zoiets in een access database kunnen bouwen. Je wilt simpele relaties leggen en de relaties naar voren kunnen brengen. Ik kan zo niks anders bedenken waar dat mee kan maar er zijn vast legio oplossingen.

En dan zou je die access database met visio kunnen visualiseren

[PcDealer]

Eerste wat in mij opkomt: Veeam One.