Difference: ComputingAdminProvisioningSystem ( vs. 1)

Revision 12015-04-27 - samir

Line: 1 to 1
Added:
> >	Description We use Foreman as a bare metal provisioning system. Foreman installs Puppet at the server kickstart, already connecting back to the Puppet Master. The Puppet Master CA has a policy to auto-approve machines that have a valid .tier2 DNS. That goes along the lines that Foreman controls the local DNS, so if it's there, is because we included it through Foreman. As it's a local network we don't need to be more secure than that. Tier-2 At the Tier-2, the server that manages Foreman and also all* Puppet components is t2-headnode-new. It has a Foreman Smart-Proxy, a Foreman Server, a Puppet Master configured with Passenger through Apache and a Puppet CA. All deployed with the respective default manuals in the "product's website". Tier-3 The T3 setup is more minimalistic. Mostly because we could benefit from the same Foreman Server as we use for the Tier-2. As a consequence it was only deployed a smart-proxy with all associated services (DNS, DHCP, TFTP, etc) in "nas-1-1". We're using Chef for the T3 and the code is here. I don't think it was ever tested out of VMs thought. We have a chef server in t3-headnode-new. Specifics. The best host group for T2 installs in the private network is "tier-2" The best partitioning schema for non-critical machines (nodes) is "dynamic partitioning rocks migration". The features are : 1 - it will size /wntmp to 20 * NCores GB. 2 - IF /data1 is present in /dev/sda, all other partitions will be killed but that one. All other partitions will be re-created but /data1 will be left alone. There's an edge case where we re-use a disk from a datanode, with /data25 label still there. Cure is going to TTY2 during reinstall, killing the only partition in /dev/sda and rebooting, then it will pickup the normal Anaconda partitioning. -- Main.samir - 2015-04-27

Line: 1 to 1

Added:

>
>

Description

We use Foreman as a bare metal provisioning system. Foreman installs Puppet at the server kickstart, already connecting back to the Puppet Master. The Puppet Master CA has a policy to auto-approve machines that have a valid *.tier2 DNS. That goes along the lines that Foreman controls the local DNS, so if it's there, is because we included it through Foreman. As it's a local network we don't need to be more secure than that.

Tier-2

At the Tier-2, the server that manages Foreman and also all Puppet components is t2-headnode-new. It has a Foreman Smart-Proxy, a Foreman Server, a Puppet Master configured with Passenger through Apache and a Puppet CA. All deployed with the respective default manuals in the "product's website".

Tier-3

The T3 setup is more minimalistic. Mostly because we could benefit from the same Foreman Server as we use for the Tier-2. As a consequence it was only deployed a smart-proxy with all associated services (DNS, DHCP, TFTP, etc) in "nas-1-1".

We're using Chef for the T3 and the code is here. I don't think it was ever tested out of VMs thought. We have a chef server in t3-headnode-new.

Specifics.

The best host group for T2 installs in the private network is "tier-2"
The best partitioning schema for non-critical machines (nodes) is "dynamic partitioning rocks migration". The features are : 1 - it will size /wntmp to 20 * NCores GB. 2 - IF /data1 is present in /dev/sda, all other partitions will be killed but that one. All other partitions will be re-created but /data1 will be left alone. There's an edge case where we re-use a disk from a datanode, with /data25 label still there. Cure is going to TTY2 during reinstall, killing the only partition in /dev/sda and rebooting, then it will pickup the normal Anaconda partitioning.

-- Main.samir - 2015-04-27

View topic | History: r1 | More topic actions...

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback