[mpich-discuss] MPICH Hardware Configuration

Reuti reuti at staff.uni-marburg.de
Mon Nov 14 15:47:43 CST 2011


Am 14.11.2011 um 22:26 schrieb Nicolas Rosner:

> You're welcome; glad to hear the information was useful. By the way,
> if you decide to build a private subnet for your minis so that, as
> typically done, any node can reach any other but only one may be
> reached from the outside, the multilink multihoming feature of OS 10.7
> may prove useful to you (since physically adding a 2nd NIC to a Mini
> is probably nontrivial).

An USB - Ethernet dongle could do it, or a ThunderBolt - Ethernet adapter like in the Sonnet RackMac Xserve enclosure:

http://www.sonnettech.com/product/rackmacminixserver.html

-- Reuti


> Of course this depends on what "outside"
> means in your case, as well as existing routers and security policies.
> 
> I see what you mean by hardware best practices. While that does sound
> useful, I think the vast variety of hardware, software and use context
> combinations out there could complicate the viability of such a guide
> in practice. My guess is that trying to limit its scope to the
> "typical" setup or two would yield something too generic to add real
> value over existing howtos on the matter, while attempting to cover a
> more representative range of scenarios might quickly become a
> significant endeavor in its own right.
> 
> Good luck,
> Nicolás
> 
> 
> 
> On Mon, Nov 14, 2011 at 1:11 PM, Jon Smejkal <czechm8 at aps.anl.gov> wrote:
>> Hi Nicolás,
>> 
>> Thank you for your response. You have been very helpful and have provided
>> some things to consider.
>> 
>> As for the documentation side, I was looking for a "hardware requirements"
>> or "hardware best practices" kind of document. I agree that tackling the
>> hardware side is a whole field unto itself and the MPICH2 team has better
>> things to do. I guess I was looking for a jumping off point.
>> 
>> Thank you again for your input,
>> Jon
>> 
>> 
>> 
>> On 11/11/11 9:05 PM, Nicolas Rosner wrote:
>>> 
>>> Hello Jon,
>>> 
>>>> Can I just plug them all into the same network switch
>>>> and access them from a desktop user machine?
>>> 
>>> Short answer: Yes.
>>> 
>>> Longer answer (sorry if somewhat off-topic):
>>> 
>>> I know near-zero about your more specific requirements, e.g. how
>>> exactly you need to access the minis, whether the desktop machine
>>> would be on the same subnet, whether it'd be a Mac, what OS version,
>>> etc. Such details could actually matter if you want to rely on the
>>> 'ultra-user-friendly' side of the OS X Srvr admin tools, which AFAIK
>>> can be quite picky about, say, your desktop OS X machine being exactly
>>> the same animal-version-number as your servers and whatnot.
>>> 
>>> [ -->  http://support.apple.com/kb/HT1822 ]
>>> 
>>> OTOH, if a slightly less streamlined "admin experience" (ha) doesn't
>>> scare you too much, then you should be just fine. It is a server
>>> platform, after all, so running headless is what it's designed for.
>>> Since both ssh and vnc daemons are bundled, even your worst-case
>>> scenario still would include quite decent platform-agnostic remote
>>> access. I hope this answers your question.
>>> 
>>> 
>>>> or will I have to use one of them as a head node?
>>>> Can you point me in the right direction?
>>> 
>>> Depends on what you mean by 'head node' here. No, you don't need to
>>> sacrifice a compute node unless you want to. Any other 10.7 Mac should
>>> probably work for the Apple-blessed paradigm. And any old PC with a
>>> vnc and a ssh client would, at the very least, get you graphics and
>>> text-based access with little or no effort.
>>> 
>>> But yes, you probably will want to configure a 'headless head node'
>>> (no monitor, still usable for HPC, just a slightly different config)
>>> in the sense of an entry point to the cluster LAN. Otherwise you'd
>>> have to either expose every node or none at all to the outside world
>>> (be that the internet, the rest of your office or whatever).
>>> 
>>> 
>>>> documentation and support pages but see no
>>>> reference on how to tackle the hardware end
>>> 
>>> I'm not related to the MPICH2 team, but an end user from South
>>> America, so this is merely a personal opinion on this -- but I'm not
>>> sure I got it -- were you thinking of something akin to a "How to set
>>> up a network" chapter on the user guide?
>>> 
>>> If so, I'd have to disagree. I think there are many good sources for
>>> that kind of thing on the Web. I'd rather see the MPICH2 people keep
>>> up their good work at developing and supporting MPICH2 itself, rather
>>> than losing focus on the prerequisites. Sorry if you meant something
>>> else and I misunderstood!
>>> 
>>> Good luck, hth,
>>> 
>>> Nicolás
>>> _______________________________________________
>>> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
>>> To manage subscription options or unsubscribe:
>>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>> 
>> --
>> Jon Smejkal
>> Information Technology
>> Advanced Photon Source
>> Argonne National Laboratory
>> 630.252.5616
>> 
>> _______________________________________________
>> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
>> To manage subscription options or unsubscribe:
>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>> 
> _______________________________________________
> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
> To manage subscription options or unsubscribe:
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
> 



More information about the mpich-discuss mailing list