Distributed Systems : Workshop 2

Work proposal 2 for Thursday 13.9.2012.

Note: If you did not have time to do the small programming exercise last week,
it is better to do that now (in case you notice you need to join the C
Programming Course) and save one or both of the survival skills tasks below for
next week.

Form groups of 2-4 people.

1. An architecture is a way of modelling (or organizing) a system, explaining
the different roles of components and their interactions. The Tanenbaum book
describes four architectural styles: layered architectures, object-based
architectures, data-centered architectures and event-based architectures.

For example the TCP/IP stack model and the OSI (Open Systems interconnection)
models are layered, while the Domain Name Service (DNS) is generally described
as a tree graph of nodes connected into an object-based architecture. Many
services can be described in terms of a simple client-server architecture, while
others require a multitiered architecture.

Recall what the different architecture terms here mean and explain them to each
other. Can you think of ways in which different architecture models or styles
might affect your thinking when designing distributed systems?

2. Recall the terms network operating system, distributed operating system and
middleware and explain them in the group.

What is the primary benefit of adding a common layer, e.g. of middleware, to a set of computation nodes?

3. Survival Skills: SSH key management.

For the upcoming exercises involving the computational cluster, you will need
to set up a key pair for ssh (recall last Thursday's task 4).

Take a look at the manual pages ('man ssh-keygen') and generate a private and
public key pair for yourself. To use the key pair, the public key must be
accessible in the Ukko cluster node you will use. Remember to protect your
private key with a passphrase that is at least as strong as your department
login's password, because this key is equivalent to your login and
password.

(You can even use the same password as is your department login, as according to
a comment from our IT support. "If that's leaked, you're done for anyway." ;)
The key passphrase is not actually stored on the key. Just do not mix your
department password into any access to your home computer or other systems.)

Install your generated key to your department (fs) home directory according to
the instructions linked below.

UPDATE: Actually, since Ukko can only be connected to from inside the department network, you will need to have your private key on melkki (or similar) and public key ... in the same home directory ("on Ukko" - melkki and ukko have the same home directory for you). You can also have a private-public keypair on your laptop to connect to melkki. (The best option in the general case is to generate a different keypair for each computer that stores a private key, but if these are the only two places you use the same private key, if something goes wrong you're just going to have to 'rm authorized_keys' instead of doing more fine-grained removals...)

Reading material as background and further instructions: OpenSSH key management,
part 1:
http://www.ibm.com/developerworks/library/l-keyc/index.html

Survival skills learned: How ssh keys work. The keys are needed to interact
meaningfully with multiple nodes in the department network, such as in any
exercises done on the cluster computer. While in normal department existence you
can get along without this login aid, this is setup to save your time in later
exercises.

4. Survival Skills: A first glance at the Ukko cluster.

Read the instructions on how to use the department high performance cluster
Ukko.  http://www.cs.helsinki.fi/en/compfac/high-performance-cluster-ukko

Test your ssh key by connecting to an Ukko cluster node. First examine the
report at http://www.cs.helsinki.fi/ukko/hpc-report.txt to find a node that is
live and not in use by a research project.

Then use ssh-add to activate your key identity unless you already have done so.

Log on to the chosen Ukko cluster node, make sure your password was not asked,
and take a look around before logging off:

'ls' - (directory listing) notice that you have access to your home directory
here too. It's just like another interactive server setup!

'who' - are other interactive users logged in on the same node? For contrast,
you can try this command on the actual department interactive servers.

'uptime' - how long has the node been up and running? Do they boot these nodes
every week?

'top' - you can look for resource-intensive jobs running on the node, 'man top'
for documentation. 'q' to quit.

Reading material as background and further instructions: OpenSSH key management,
part 1:
http://www.ibm.com/developerworks/library/l-keyc/index.html

Survival skills learned:

The Ukko cluster: This is a part of the department's computational
infrastructure that is in use by several research groups at the distributed
systems and networking, and if you take the Distributed Systems Project course
you may well end up back on Ukko for that, or your master's thesis on the
specialization line. Within the Distributed Systems course, we will have a
Friday exercise next week involving the Ukko cluster which is going to be a
piece of cake after this.