You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Overview

We have decided to set up virtual machines on the Fermilnx boxes. This will enable us to map existing glastlnx boxes onto virtual machines, to first approximation keeping the existing break down of applications/ (virual) servers.

Proposed mapping

See also: ?Applications on glastlnx machines and fermilnx migrationServers and Aliases.

Existing

New

Aliases

Comment

glastlnx03

fermilnx-v01

 

 

glastlnx04

fermilnx-v02

 

 

glastlnx05

fermilnx-v03

 

 

glastlnx07

fermilnx-v04

 

This machine requires user login

glastlnx08

fermilnx-v05

 

 

glastlnx09

 

 

This is now used by EXO as a database server. A replacement machine is (about to be) ordered.

glastlnx10

fermilnx-v06

 

 

glastlnx12

fermilnx-v07

 

 

glastlnx13

fermilnx-v08

 

 

glastlnx16

fermilnx-v09

 

 

glastlnx17

fermilnx-v10

 

 

glastlnx18

fermilnx-v11

 

There is also a SRS tomcat server in this machine -- it should migrate somewhere else

glastlnx19

fermilnx-v12

 

There is also an EXO tomcat server on this machine -- it should migrate somewhere else

glastlnx20

fermilnx-v13

 

 

glastlnx21

fermilnx-v14

 

 

glastlnx22

fermilnx-v15

 

 

glastlnx23

fermilnx-v16 (whoops, one too many)

 

 

Next Steps

We should identify a set relatively standalone services to move to fermilnx-v* machines. Some suggestions:

  • Test tomcat server
  • Data catalog crawler
  • Astro server loaders

As we move services we should also check which version of Java they are using, and where possible switch to Java 7.

We will need to move aliases to point to new machines, in a phased way. It would probably also be good to introduce new aliases for some services which do not currently have them.

Goals

We need to identify critical applications and estimate resource usage for these applications and spread them across the servers accordingly. Since we are using fewer servers, we are increasing the number of services per machine so we want to limit effects incurred from possibly misbehaving applications. I'm going to try to rate the applications on a scale of 1-5 in these 3 metrics. The first metric is the priority of the application during a normal power scenario, assuming SLAC is not in a power outage scenario. The second metric is the estimated CPU usage and memory usage of the application. The third metric is the possibility an application will misbehave and abuse resources for an extended amount of time.

Application

Priority/Criticality

CPU/Memory Requirements (average/peak)

Resource abuse potential

Pipeline (Production)

5

2/4

3

Pipeline Mail client

5

1/2

1

Pipeline Jobcontrol clients

5

1/2

2

Datacatalog server (crawler)

3

2/2

2

Astroserver (loader)

2

2/5

3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Resource management

Ideally we could put all applications on a few machines without worrying about interference from other applications. In practice this isn't practical. It's been suggested to use virtual machines and split up services among the machines.

  • No labels