IDRAC8Investigation < DICE

DICE Web>IDRAC8Investigation (14 Oct 2016, IanDurkacz) (raw view)EditAttach
---+ Dell iDRAC 8 investigations

---++ Background

For our current generation of Dell servers (namely the '13th generation' - e.g. R730), we will be standardising on either the 'iDRAC8 Basic' (for Dell 200-500 servers) or the 'iDRAC8 Express' (for Dell 600 servers, and above) for remote out-of-band access. (See  item 5 of the [[http://www.dice.inf.ed.ac.uk/operational/meetings/2016-02-24/inf-unit-report.html#idrac8][Inf Unit's report to the Operational Meeting of 24.02.16]] for more discussion and context on all of this.) 

As well as support for IPMI V2.0, the various types of iDRAC8's offer some proprietary features which _might_ be useful to us: this note summarizes what we've found out and concluded about such things in our investigations to date.

---++ Findings

   1. All iDRAC8s implement IPMI v2.0. For our 'usual' IPMI purposes (power control, SOL console), the iDRAC8 seems the same as any other Dell DRACs/BMCs we have, and should be configured and used in the same way.
   1. All iDRAC8s also offer remote 'out-of-band' access ('out-of-<em>IPMI</em>-band', that is), via either ssh or HTTP. Since our default configuration has all iDRACs located on an _unrouted_  private subnet, a _direct_ network connection to either of those interfaces can only be made from the designated console server at each of our sites.
      1. ssh:
         i. The ssh interface presents a so-called 'Server Management Command Line Protocol' (SMCLP) interface. That's a proposed industry-standard, and the details of the Dell implementation are described in chapter 18 of the iDRAC8 manual. (See the 'References' section.) 
         i. We don't think this interface offers much to us, apart from a 'reset' capability which might be useful in remotely resetting an iDRAC8 in circumstances where its IPMI interface has become unresponsive.
      1. HTTP:
         i. The HTTP interface is somewhat awkward to use: since our iDRACs are located on an unrouted private subnet, HTTP traffic from a desktop machine to the iDRAC needs gatewaying in some way. One way to achieve that is to set up Firefox as a SOCKS proxy: use [[PrinterWebInterface][these instructions]], substituting the site console server for =infcups=.
         i. The HTTP interface has one feature which sounds like it should be useful to us, namely 'update firmware.' However:
            * We have so far _not_ been able to make this work at all.
            * If this facility is to be used against some kind of firmware repository available on the network, then: _either_ some proxy gatewaying will need to be set up in the iDRAC8's network configuration - and that doesn't seem possible; _or_ the repository will need to be located on the same unrouted private subnet as are all iDRACs.
            * We now think that this facility is intended to be used in conjunction with a _locally-maintained_ web server on which Dell firmware updates are made available, rather than some kind of Dell-maintained repository available over the Internet. 
            * We think that the new OS-level _dsu_ utility will provide us a generally better method of applying firmware updates than the HTTP mechanism provided by the iDRAC8: see DellFirmwareUpdates for more discussion.

---++ Cabling standards

   1. The iDRAC has its own dedicated NIC, which was used on test machine _girassol_ without difficulty. Test machine _gaivota_ (the same model of server) had the iDRAC connected via LOM1, that is, piggy-backed on the first normal NIC. Either method works, but, at the [[http://www.dice.inf.ed.ac.uk/operational/meetings/2016-07-27/agenda.html][Operational meeting of 27/07/16]] we decided to standardise on the piggy-back connection rather than use the iDRAC's own NIC. The reason for that choice is to minimize the number of network cables and switch ports which need to used when connecting the machine. A counter-argument _might_ be the iDRAC's own NIC is less susceptible to failures at the OS level: certainly, we have seen cases of iDRACs becoming uncontactable over the network which are resolved by a machine OS reboot - so it _must_ be the case that the device drivers etc. supplied by the OS play some part in the network piggy-backing chain.

---++ References

   1. Several iDRAC (and Lifecycle Controller) manuals have been put in the MPU group area: ==/afs/inf.ed.ac.uk/group/mp-unit/hardware/DellDocs/iDRAC==
   1. DMTF [[http://www.dmtf.org/sites/default/files/standards/documents/DSP0214.pdf][Server Management Command Line Protocol (SMCLP) Specification ]]
Topic revision: r4 - 14 Oct 2016 - 14:54:58 - IanDurkacz
DICE.IDRAC8Investigation moved from DICE.InitialiDRAC8Findings on 14 Oct 2016 - 13:13 by IanDurkacz - put it back
DICE
This is WebLeftBar
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies