[mpich-discuss] MPICH Hardware Configuration

Nicolas Rosner nrosner at gmail.com
Mon Nov 14 15:26:00 CST 2011


Hi Jon,

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). 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
>


More information about the mpich-discuss mailing list