Bekijk Volledige Versie : iDRAC 6 dedicated nic of shared nic?
Hallo,
Wij zijn nu een groot aantal servers aan het uitbreiden met Dell iDRAC6 enterprise kaarten.
Al deze kaarten hebben een dedicated network interface waarmee ze kunnen communiceren met het internet.
Nu vroeg ik mij af, is het per see nodig deze dedicated nic te gebruiken?
Ik heb de iDRAC eens ingesteld op shared nic, en dan werkt deze ook gewoon volledig naar behoren (inclusief vflash, virtual console en virtual media) via de gedeelde netwerk interface.
Aangezien het om een groot aantal servers gaat waar zeer incidenteel iDRAC gebruikt word voor een herinstallatie of remote reboot is het zonde om voor elke server een aparte switchpoort te moeten gebruiken hiervoor.
Zijn er performance issue's als je besluit de iDRAC gewoon shared over de bestaande netwerkinterface te laten lopen?
Heeft het overige verkeer er last van, of is het zo'n klein process (en zo weinig data als het ware) dat dit geen probleem moet zijn.
Nu kan als argument aangevoerd worden dat als de switchpoort kapot gaat je ook niet meer de server kunt bereiken, maar hoe vaak komt dat nou voor als je degelijke apparatuur gebruikt..
Face the facts, als de switchpoort kapot gaat en je vervolgens wel je iDRAC kunt bereiken (over je dedicated nic) dan sta je ook maar wat te kijken want meer dan dat kun je vervolgens ook niet.
Graag zou ik willen weten of iemand van jullie hier meer ervaring mee heeft.
Bvd!
dennis0162
01/01/12, 23:47
Wij hebben Drac/iDRAC ook altijd gewoon over de shared NIC lopen, nog nooit performance issues gehad.
Het enige is dat je de NIC niet meer kan gebruiken voor een trunk.
Er is een zekere mate van medewerking van het OS vereist om de poort netjes te delen.
Zo werkte bij oudere versies van FreeBSD de ipmi functie niet meer na het opstarten, tenzij je een beaalde kernel optie instelde (allow_asf)
Die optie staat tegenwoordig standaard aan, maar het feit dat het OS invloed kan hebben op het functioneren van de kaart zou je wel als een risico kunnen zien.
Vraag me af in hoeverre je er van op aan kan dat deze het blijft doen als de kernel crashed, of er een bug in de netwerkcode zit.
Er is een zekere mate van medewerking van het OS vereist om de poort netjes te delen.
Zo werkte bij oudere versies van FreeBSD de ipmi functie niet meer na het opstarten, tenzij je een beaalde kernel optie instelde (allow_asf)
Die optie staat tegenwoordig standaard aan, maar het feit dat het OS invloed kan hebben op het functioneren van de kaart zou je wel als een risico kunnen zien.
Vraag me af in hoeverre je er van op aan kan dat deze het blijft doen als de kernel crashed, of er een bug in de netwerkcode zit.
Maar bij menig server zit alleen iDRAC Express, welke geen dedicated NIC heeft.
Deze is dus altijd afhankelijk van het OS, echter heb ik tot nu toe nog nooit problemen gehad (Windows / ESX / Xen server)
Dus het zal wel allemaal verholpen zijn neem ik aan.
Wel zeer nuttige informatie! bedankt!
Ik zou voor dedicated gaan, i.v.m. meerdere redenen, onder andere; Bij een DDoS kan je via de DRAC nog bij je server, als je voor shared gaat niet.
Aangezien het om een groot aantal servers gaat waar zeer incidenteel iDRAC gebruikt word voor een herinstallatie of remote reboot is het zonde om voor elke server een aparte switchpoort te moeten gebruiken hiervoor.
Waarom zonde? Wat kost tegenwoordig een switch nou?
Deze is dus altijd afhankelijk van het OS, echter heb ik tot nu toe nog nooit problemen gehad
Maar heb je daarbij blauwe schermen of kernel panics gehad?
Dat de ipmi functie het doet zolang het besturingssysteem meewerkt en juist functioneert geloof ik wel.
Maar voor normale beheerswerkzaamheden kan je ook ssh gebruiken.
Waar ik echter bezorgd om ben zijn situaties dat het systeem ECHT vast zit, en je de kaart wilt gebruiken om te rebooten.
Weet je 100% zeker dat als je hem het hardst nodig hebt, deze het blijft doen...
Maar heb je daarbij blauwe schermen of kernel panics gehad?
Dat de ipmi functie het doet zolang het besturingssysteem meewerkt en juist functioneert geloof ik wel.
Maar voor normale beheerswerkzaamheden kan je ook ssh gebruiken.
Waar ik echter bezorgd om ben zijn situaties dat het systeem ECHT vast zit, en je de kaart wilt gebruiken om te rebooten.
Weet je 100% zeker dat als je hem het hardst nodig hebt, deze het blijft doen...
Zit een kern van waarheid in, echter werkt de iDRAC kaart ook gewoon als de server nog aan het booten is of uit staat.
Zelfs als er geen OS geladen is kun je via de iDRAC kaart gewoon meermaals rebooten zonder problemen.
Waarom zou de werking opeens anders zijn zodra er een OS geladen word?
@Xaban: een switch kost tegenwoordig geen drol meer, maar ik vind het zonde om op je dure access switches poortjes in gebruik te nemen voor een iDRAC kaart, liever op een (extra) tweede simpele switch welke je ophangt.
Hier staan de DRAC's op dedicated nic. Om zeker weten nergens van afhankelijk te zijn. Het is nou net op het moment dat wat niet meer werkt je wil kunnen terugvallen op die kaarten.
Verder staan er hier ook telkens 2 nic's geteamed voor internet access.
Ook in geval van gescheiden management netwerk zodat DRAC's bijvoorbeeld alleen via VPN bereikbaar zijn is het lastig om onder de dedicated poort uit te komen. Die extra switch voor management netwerk kost de wereld ook niet.
@Xaban: een switch kost tegenwoordig geen drol meer, maar ik vind het zonde om op je dure access switches poortjes in gebruik te nemen voor een iDRAC kaart, liever op een (extra) tweede simpele switch welke je ophangt.
Je moet dure switches inderdaad niet gebruiken voor je management, dat kan zoals je al aangeeft op een goedkoper model.
Kan je gaan voor 2 opties:
- Je tweede switch interconnect je met je access switch: Echter zonde van je IP's.
- Je hangt een management server op, je DRACs geef je een interne IP.
Waarom zou de werking opeens anders zijn zodra er een OS geladen word?
Als de werking niet anders zou zijn, waarom stoppen de kaartjes dan met functioneren zodra (een oude versie van) FreeBSD geladen wordt?
Hier zitten mijn ipmi's ook op dedicated verbindingen op management lan (internal ip's) die via firewall/vpn bereikbaar zijn. Het probleem dat ik had toen ik ze shared wilde zetten was dat vlan's niet meer goed werkte en de ipmi begon te flippen, waardoor de eigenlijke verbinding ook packet loss kreeg. Maar dat zou ook aan het ipmi type kunnen liggen, persoonlijk zou ik voor volledig gescheiden lan gaan kwa besparing ip adressen en beveiliging.
rensariens
02/01/12, 10:39
Ook hier zitten ze op dedicated NIC. Dit is voornamelijk vanwege ervaringen met Supermicro IPMI (minder stabiel en trager wanneer shared). Zitten overigens gewoon op een oude 100mbit switch.
Tim.Bracquez
03/01/12, 00:54
Los ervan is dit bij IPMI bij SuperMicro soms wel een probleem onder bv XenServer (bepaalde versies; bios update)
Hiervoor altijd apart, oudere switches (100Mbit) komen gewoon aan het management gedeelte. Kan je mooi alles upgraden, hier volledig gescheiden en dient desnoods als active spare in sommige situaties.
Het is wel wat extra bekabeling maar dit valt opzich wel mee.
EDIT: The-BosS en resariens waren me voor