Difference between revisions of "Einstein"

From Nuclear Physics Group Documentation Pages
Jump to navigationJump to search
Line 1: Line 1:
Note: This is the page for the NEW EINSTEIN - 8 core server from Microway
+
Einstein will soon be a VM. See [[old einstein]].
 
 
The previous einstein hardware is described in the previous page for Einstein at [[old einstein]]
 
 
 
= New Microway Server =
 
 
 
The new einstein is a 2 quad-CPU server in a 2U rackmount chassis put together nicely by Microway. It arrived at UNH on 11/24/2009. The system has an Areca RAID card with ethernet port and an IPMI card with ethernet port. The motherboard is from Super Micro. Details need to be put here!
 
 
 
 
 
 
 
== Important things to remember before this system takes on the identity of Einstein ==
 
 
 
# The ssh fingerprint of the old einstein needs to be imported.
 
# Obviously, all important data needs to be moved: Home Directories, Mail, DNS records, ... (what else?)
 
# Fully test functionality before switching!
 
 
 
== Configurations Needed ==
 
 
 
# RAIDs need to be setup on Areca card.
 
# Mail system needs to be setup
 
# Webmail needs to be setup. Uses Apache?
 
# DNS needs to be setup.
 
# Backup needs to be made to work.
 
# rhn_config  - I tried this but our subscriptions seem messed up. (Send message to customer support 11/25/09)
 
 
 
== Initialization ==
 
 
 
Server arrived 11/24/2009, was unpacked, placed in the rack and booted on 11/25/2009.
 
 
 
Initial configuration steps are logged here:
 
* Initial host name is gourd (gourd.unh.edu) with eth0 at 10.0.0.252 and eth0.2 (VLAN) at 132.177.88.75
 
* The ARECA card is set at 10.0.0.152. The password is changed to the standard ARECA card password, user is still ADMIN.
 
* The IPMI card was configured using the SuperMicro ipmicfg utility. The net address is set to 10.0.0.151. Access is verified by IPMIView from Taro. The grub.conf and inittab lines are changed so that SOL is possible at 19200 baud.
 
* The LDAP configuration is copied from Taro. This means it is currently in '''client ldap''' mode, and needs to be change to an '''ldap server''' before production. You can log in as yourself.
 
* The autofs configuration is copied from Taro. The /net/home and /net/data directories work.
 
* The sudoers is copied from Taro, but it does not appear to work - REASON: pam.d/system-auth
 
* Added "auth        sufficient    pam_ldap.so use_first_pass" to /etc/pam.d/system-auth - now sudo works correctly.
 
 
 
== Disks and Raid Configuration ==
 
 
 
'''Current Disk usage Estimates for Einstein:'''
 
{| style="wikitable;" border="0"
 
| Mail (/var/spool):
 
| approx. '''30GB'''
 
|-
 
| Home Folders (/home):
 
| approx. '''122GB'''
 
|-
 
| Virtual Machines (/data/VMWare on Taro): 
 
| approx. '''70GB'''
 
|-
 
| LDAP Database (/var/lib/ldap):
 
| approx. '''91MB'''
 
|}
 
<br/>
 
 
 
Disk sizes in the following tables are based roughly on these current usage estimates with plenty of extra space to grow. They can be adjusted as appropriate to better suit our needs, and to make these designs more cost effective.
 
 
 
<hr/>
 
 
 
=== Proposed Configuration 1 ===
 
 
 
This configuration is designed to modularize storage and keep related data on separate mirrors. Could be useful if we have a failover system, such as the old Einstein hardware, because individual components ( Mail, home folders, etc ) could be relocated physically to another machine in the event of some failure rather than copying large amounts of data over the network. This design could be modified to use fewer drives by storing Virtual machines either on the /var array or the /home array, opening up the bays to store spare drives.
 
 
 
{| style="wikitable;"  border="1"
 
! Drive Bay
 
! Raid Type
 
! Contents
 
! Volume Size
 
! Disk Size
 
|-
 
| 1
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Operating System ( / )
 
| rowspan="2" | 250 GB
 
| 250 GB
 
|-
 
| 2
 
| 250 GB
 
|-
 
| 3
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Mail/LDAP ( /var )
 
| rowspan="2" | 250 GB
 
| 250 GB
 
|-
 
| 4
 
| 250 GB
 
|-
 
| 5
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Home Folders
 
| rowspan="2" | 500 GB
 
| 500 GB
 
|-
 
| 6
 
| 500 GB
 
|-
 
| 7
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Virtual Machines <br> Data
 
| rowspan="2" | 250 GB
 
| 250 GB
 
|-
 
| 8
 
| 250 GB
 
|}
 
<br/>
 
<hr/>
 
 
 
=== Proposed Configuration 2 ===
 
 
 
This configuration provides a larger amount of contiguous storage space than the previous design with redundancy provided by either a Raid 6 or Raid 5 array. Raid 5 would provide more usable storage, but Raid 6 will withstand more than one disk failure. It may be preferable to err on the side of caution with our user's data and use a Raid 6 for home folders.
 
 
 
{| style="wikitable;"  border="1"
 
! Drive Bay
 
! Raid Type
 
! Contents
 
! Volume Size
 
! Disk Size
 
|-
 
| 1
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Operating System ( / )
 
| rowspan="2" | 250 GB
 
| 250 GB
 
|-
 
| 2
 
| 250 GB
 
|-
 
| 3
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Mail/LDAP ( /var )
 
| rowspan="2" | 250 GB
 
| 250 GB
 
|-
 
| 4
 
| 250 GB
 
|-
 
| 5
 
| rowspan="4" | Raid 5 '''or''' <br/> Raid 6
 
| rowspan="5" | Home Folders <br/> Virtual Machines <br/> Other data
 
| rowspan="4" | 1000 GB (Raid6) <br/> 1500GB(Raid5)
 
| 500 GB
 
|-
 
| 6
 
| 500 GB
 
|-
 
| 7
 
| 500 GB
 
|-
 
| 8
 
| 500 GB
 
|}
 
<br/>
 
<hr/>
 
 
 
=== Proposed Configuration 3 ===
 
 
 
This configuration would create one large data store for all user and system data, which could be stored on separate appropriately sized partitions. This design is less modular, but uses fewer drives than previous designs while leaving bays open to store spares in the event of a drive failure.  
 
 
 
{| style="wikitable;"  border="1"
 
! Drive Bay
 
! Raid Type
 
! Contents
 
! Volume Size
 
! Disk Size
 
|-
 
| 1
 
| rowspan="2" | Raid 1
 
| rowspan="2" | Operating System ( / )
 
| rowspan="2" | 250 GB
 
| 250 GB
 
|-
 
| 2
 
| 250GB
 
|-
 
| 3
 
| rowspan="4" | Raid 6
 
| rowspan="4" | Home Folders ( /home ) <br/> Mail/LDAP ( /var ) <br/> Virtual Machines
 
| rowspan="4" | 1000 GB
 
| 500 GB
 
|-
 
| 4
 
| 500 GB
 
|-
 
| 5
 
| 500 GB
 
|-
 
| 6
 
| 500 GB
 
|-
 
| 7
 
| None
 
| Empty / Spare Drive
 
| 0
 
| 250/500 
 
|-
 
| 8
 
| None
 
| Empty / Spare Drive
 
| 0
 
| 250/500
 
|}
 
<br/>
 
<hr/>
 

Revision as of 13:50, 11 December 2009

Einstein will soon be a VM. See old einstein.