Build an m2 Anvil! - Detailed
|
AN!Wiki :: Build an m2 Anvil! - Detailed |
 |
Warning: This is an in-progress document. Do not expect anything here to be accurate or correct. This warning will be removed when the guide is completed. You can track the progress on Striker's Github page. |
This guide will walk you through all the steps needed to build an Anvil! platform.
 |
Note: This guide covers a lot of background reasoning and high-level discussion of the Anvil! platform in general. If you don't care about this and want concise instructions, see the link below. |
A What?
An Anvil! Platform is, fundamentally, a system designed to keep your (virtual) servers running, if at all possible.
An Anvil! Platform contains three parts;
- A hardware architecture
- An easy to use web interface, called Striker.
- An autonomous "decision engine", called ScanCore.
Collectively, these parts for the Anvil! platform, the first Intelligent Availability™ platform ever.
The Anvil! Architecture
|
Note: The Anvil! architecture is a vendor-neutral platform. However, some hardware may not yet have a ScanCore agent yet. If you have as-yet unsupported hardware, please let us know. |
We'll go into the architecture further down, but in brief, it fulfils the 'complete stack redundancy' requirement of IA.
In brief, the architecture includes;
- Dual network-connected UPSes
- Dual network-switched PDUs
- Dual stacked ethernet switches
- Dual server host nodes
- Dual Striker dashboards
Together, they provide a platform in which all components are fully redundant and electrically and mechanically isolated. This allows the Anvil! platform to survive not just a failure, but also recovery and normal maintenance without service interruption.
The Striker WebUI
The Striker WebUI is designed to be as easy to use as possible. This is not for your benefit, but instead for the protection of the Anvil! itself.
This is in-line with the Remove the human part of "Intelligent Availability".
The consistent Anvil! architecture allows Striker to make a lot of assumptions, dramatically assisting with the "simplicity" goal.
The ScanCore Decision Engine
ScanCore is the heart of the Anvil! platform's Intelligent Availability, providing the Intelligent_Availability#Intelligent_Availability_Is_Proactive proactive component of Intelligent Availability.
ScanCore runs on all Anvil! nodes and Striker dashboards. On each machine, it invokes all available scan agents and then analyses the results to make "big picture" decisions on what, if anything, to do to best protect the hosted servers.
Fundamentally, this results in one of two actions;
- Preventative Live Migration
- Load Shedding
Here is an example of both scenarios.
Power loss
Power is lost to one UPS, no action is taken because the backup UPS has power. Later, power is lost to both UPSes, ScanCore determines the greatest threat to availability is no longer component failure, but instead, depletion of the batteries. Redundant node is powered off to shed load and extend run-time. Power stays out for too long and the strongest UPS drops below a minimal run-time and ScanCore gracefully shuts down hosted servers and then the active node. Later, power is restored. Striker dashboards boot and begin monitoring the UPS charge rate. When safe, the nodes are rebooted and hosted servers are started, all autonomously.
ScanCore can differentiate between a local node suffering a cooling failure versus an environmental loss of cooling. When the latter is detected, it will also shed load to reduce thermal output and slow the rate of heating. Likewise, when the room returns to nominal temperatures, ScanCore will restore full redundancy.
Hardware Degredation
Under normal operation, both nodes are equally healthy so either can be 'active' at any given time.
At some point, the active node loses a cooling fan. ScanCore will wait a short time to ensure it isn't a transient issue, and then declare the peer is healthier and live-migrate the servers autonomously.
Should the fan not be repaired, but later a hard drive fail on the new host, ScanCore will weigh the failures against each other and decide that the cooling failure (alone, without overheating sensors) is less dangerous than a degraded RAID array, thus live-migrating the hosted servers back again.
Scan agents are free to set failure conditions and assign those conditions weight. ScanCore itself simply sums the weights from the various agents, compares them against each node and determines which node is healthier. In this way, preventative load shedding is always getting smarter.
Building an Anvil
Building an Anvil! requires a few steps;
- Selecting and assembling appropriate hardware
- Creating the install media and building the first Striker dashboard
- Using the first dashboard to build the second dashboard
- Creating an "Install Manifest" and building an Anvil! node pair
Selecting And Assembling Hardware
The Anvil! can be thought of as having three distinct parts;
- The 'Foundation Pack'; UPSes, PDUs and ethernet switches. A single foundation pack can host two or five Anvil! node pairs.
- A pair of Anvil! nodes, onto which your servers are hosted and protected.
- A pair of Striker dashboards, which can host N node pairs.
Node pairs act as a single unit to host and protect your servers. Your servers can migrate between these two nodes without interruption, and ScanCore may migrate them for you, depending on changing threats. Servers can be moved from one Anvil! to another through a cold migration process, which is useful when your needs grow beyond your first Anvil! pair. The Striker dashboards monitor and manage any number of node pairs, limited only by their ability to store ScanCore data coming from the various node pairs.
With this in mind, there are three things to consider;
- How fast does the foundation pack need to be and how many node pairs do I plan to use?
- How many servers do I plan to host on an Anvil! node pair, and what kind of performance needs do they have?
- How busy do you expect the ScanCore databases on the Striker dashboards to be?
Selecting hardware requires understanding your expected load type, understanding the performance options available and figuring out how to make it work within your budget.
Once selected and acquired, the next step is to assemble the hardware into a foundation pack, assemble the dashboards and assemble the node pairs.
Overview
This starts by download the Striker ISO generator, running it against either a RHEL or CentOS 6 ISO and it spits out an Anvil! build ISO. You can then burn this to a DVD or write it to a USB drive (using another small tool).
You boot the first Striker dashboard off of the ISO use it build up the dashboard machine.
Once done, you can get rid of the ISO if you'd like. All further installs will happen over the network!
The Striker UI acts as an "Install Target". When you enable it, you can then boot other dashboards or nodes, choose to boot of the network and they will boot and install from Striker, just the same as if you had booted up from the ISO, just a lot more conveniently.
Staged Installs
Building dashboards and nodes is a 2-stage process.
The first stage is like installing firmware on a router; It gets the base OS install and initial configuration, but it is a generic system at that point.
The second stage is where you configure the system for your environment.
The "Install Target" function handles the stage-1 install for both dashboards and nodes. The stage-2 is handled differently for dashboards and nodes, which we'll cover in a bit.
Why Do I Have To Build My Own ISO?
The Anvil! platform itself works like an appliance. That is to say, builds and manages the operating systems under the Striker dashboards and Anvil! nodes.
We had to choose early on if we were going to create our own operating system or not, and we chose not to. The additional burden of maintaining an OS would distract us from our core goal of building the most resilient, intelligent availability platform.
So how to resolve this?
For completely understandable reasons, we can't simply repackage and distribute a RHEL or CentOS based Anvil! install ISO. Red Hat and CentOS work very hard to deliver their ISOs and they want to ensure that, if their name is on something, they've tested it to be up to their standards.
So given that we don't want to create a distro, and we respect Red Hat and CentOS's trademarks, the best option available was for us to create an ISO generation tool, and that's what we've done.
You run our tool against the stock ISO and it will generate an ready-to-go Anvil! ISO.
Build the Anvil! ISO
|
Note: We've tested this tool on Fedora, RHEL and CentOS operating systems. It may not work on other distributions. If you have trouble, please contact us and we'll work to extend support to new distros. |
The build process is pretty simple;
- Download the RHEL or CentOS 6 DVD ISO.
- Download anvil-generate-iso.
- Install dependencies.
- Build the Anvil! ISO.
- (Optional) Write the ISO to a USB drive
Download the RHEL or CentOS ISO
The first question to ask is;
"Do I want to build on RHEL or CentOS?".
The answer is up to you, but it comes down to your support comfort level. If you are a proper business, then going with RHEL makes the most sense. You will need to purchase a RHEL entitlement and Resilient Storage Add-On which includes the High-Availability Add-On.
If you're looking for a "free-as-in-beer" solution, or if you want to do a proof of concept/testing, CentOS is a perfectly fine option.
Please be sure to get the 64-bit version of the 6-series release. The 32-bit is not supported, nor is the 7-series (yet).
For CentOS, download both DVD 1 and 2. For RHEL, there is only DVD 1.
Save the ISO in any directory you want, just make a note of where they are.
Download anvil-generate-iso
|
Note: When version 2 is officially released, the download location will change from github to alteeve.ca proper. |
Download the tool:
wget -c https://raw.githubusercontent.com/ClusterLabs/striker/master/tools/anvil-generate-iso
chmod 755 anvil-generate-iso
Install Dependencies
The ISO generator requires a few program to work properly. So we'll install them now:
yum install createrepo genisoimage libcdio
For Fedora:
dnf install createrepo genisoimage libcdio
For Ubuntu (tested on 16.04 LTS):
apt-get install createrepo genisoimage libcdio-utils fuseiso
For OpenSUSE (tested on 42.1):
zypper in createrepo genisoimage libcdio16 libcdio-utils
Build the ISO
|
Note: This tool requires access to the Internet to work properly. |
To build a RHEL-based Anvil! ISO, run:
./anvil-generate-iso --source ./rhel-server-6.8-x86_64-dvd.iso
To build a CentOS-based Anvil! ISO, run:
./anvil-generate-iso --source ./CentOS-6.8-x86_64-bin-DVD1.iso,./CentOS-6.8-x86_64-bin-DVD2.iso
(Note that both CentOS ISOs are listed with a ',' separating them without spaces).
Once the ISO generation starts, the process is the same for both types.
|
Note: The Anvil! ISO generator will, if you allow it, download and include third party tools, like hardware management tools. This requires reading and accepting the third party terms of use. The exact list of third part applications will grow and change as we receive feedback from testers and users. |
License agreements are important, so please do read them before proceeding.
Once your agree or decline the third party tools, the generation will start.
RHEL output:
- Generating md5sum of the source: [/home/digimer/anvil/iso/rhel-server-6.8-x86_64-dvd.iso], please wait a moment...
- The source ISO is: [RHEL 6.8, Disk 1].
- The working directory: [/home/digimer/anvil/iso/anvil/RHEL] doesn't exist.
- Can I create it (and needed subdirectories) now? [Y/n]
CentOS output:
- Generating md5sum of the source: [/home/digimer/anvil/iso/CentOS-6.8-x86_64-bin-DVD1.iso], please wait a moment...
- The source ISO is: [CentOS 6.8, Disk 1].
- Generating md5sum of the source: [/home/digimer/anvil/iso/CentOS-6.8-x86_64-bin-DVD2.iso], please wait a moment...
- The source ISO is: [CentOS 6.8, Disk 2].
- The working directory: [/home/digimer/anvil/iso/anvil/CentOS] doesn't exist.
- Can I create it (and needed subdirectories) now? [Y/n]
- Thank you, proceeding now.
In the example here, the ISO tools will create a build directory called ./anvil/iso/anvil/RHEL or ./anvil/iso/anvil/CentOS if you allow it to do so.
The rest of the build will be automated.
RHEL output (CentOS output is nearly identical);
- Thank you, proceeding now.
- The source ISO: [/data1/VMs/files/rhel-server-6.8-x86_64-dvd.iso] is not mounted. Will read and copy files directly out of the ISO.
- Reading the contents of the: [rhel-server-6.8-x86_64-dvd.iso] ISO now...
- Done. Read in: [6000] files across: [134] directories.
- Found: [3997] source packages.
- We're looking through the source ISO(s) to find which installation packages are needed.
- Please be patient! This can take a minute.
- Ready to copy files!
- Packages copied. Copying auxiliary source files now.
- Verifying 'syslinux' was created.
- The 'syslinux' directory was not in the source. Creating it now, if needed.
- Auxiliary files now in place, ready to grab Anvil! files.
- Downloading the Striker source code.
- This might take a few minutes on slow connections, please be patient.
- Downloading: [https://github.com/ClusterLabs/striker/archive/2.0.0b-rc1.zip] to: [/home/digimer/anvil/iso/anvil/RHEL/striker.zip], which is: [<unknown>]... Redirected.
- Downloading: [https://codeload.github.com/ClusterLabs/striker/zip/2.0.0b-rc1] to: [/home/digimer/anvil/iso/anvil/RHEL/striker.zip], which is: [<unknown>]... Finished! Took: [8] second(s).
- Extracting the Striker source file.
- Downloading packages from the Alteeve's Niche! repository now.
- If your connection is slow, this might take a few minutes. Please be patient.
...
<several packages downloaded>
...
- New ISO generated. Calculating sum...
- All done!
The ISO file: [/home/digimer/anvil/iso/anvil/Anvil_m2-v2.0.0b-rc1_RHEL-6.8.iso] has been generated!
- The size is: [1.02 GiB] and the md5sum is: [e72a21de00f9cc67886389cde5a165ca]
Ding! Dinner is ready!
|
Note: In the example above, version 2.0.0b-rc1 was the latest release. The version available when you generate your iso, and the resulting ISO file names, will almost certainly be different. |
You can now either burn the Anvil_m2-v2.0.0b-rc1_RHEL-6.8.iso (or Anvil_m2-v2.0.0b-rc1_CentOS-6.8.iso) ISO to a DVD disk.
Optional: Create a USB Boot Drive
|
Note: This is optional. If you don't have an optical drive on the machine you plan to make a Striker dashboard, then you can use anvil-usb-installer. |
If you plan to install from a USB drive, download anvil-usb-installer as well.
wget -c https://raw.githubusercontent.com/ClusterLabs/striker/master/tools/anvil-usb-installer
chmod 755 anvil-usb-installer
We'll need a few more programs for this tool.
yum install mkdosfs parted rsync syslinux udevadm
For Fedora:
dnf install mkdosfs parted rsync syslinux udevadm
For Ubuntu (tested on 16.04 LTS):
apt-get install dosfstools parted rsync syslinux udev
For OpenSUSE (tested on 42.1):
zypper in dosfstools parted rsync syslinux udev
|
Warning: This project will completely wipe all data from the target storage device. Be certain you are pointing anvil-usb-installer at the right target! |
In my case, my USB drive came up as /dev/sdb and I am building a RHEL version, so the command I will run is:
sudo ./anvil-usb-installer --iso ./anvil/Anvil_m2-v2.0.0b-rc1_RHEL-6.8.iso --usb /dev/sdb
-=] Anvil! USB Installer
- USB device path: . [/dev/sdb]
- Target drive: .... [ASMT 2105]
- The capacity is: . [931.51 GiB (1000.20 GB)]
- The source ISO is: [./anvil/Anvil_m2-v2.0.0b-rc1_RHEL-6.8.iso]
=======================================================================
[ WARNING ] - This device will be completely erased! All existing data
[ WARNING ] will be lost!
=======================================================================
Proceed? [y/N]
Verify this is the drive you want to overwrite!
If so, press 'y' and hit '<enter>'.
- Thank you, Proceeding
- Wiping out existing partition geometry and MBR from: [/dev/sdb]
- Creating a new partition.
Warning: The resulting partition is not properly aligned for best performance: 8192s % 65535s != 0s
- Verifying that the new partition was created successfully.
- Formatting the new partition: [/dev/sdb1]
- Writing out the master boot record to: [/dev/sdb]
- Installing syslinux on: [/dev/sdb1]
- Creating the temporary USB mount point: [/tmp/anvil_usb]
- Creating the temporary ISO mount point: [/tmp/anvil_iso]
- Mounting the USB partition: [/dev/sdb1] on: [/tmp/anvil_usb]
- Mounting the source ISO: [./anvil/Anvil_m2-v2.0.0b-rc1_RHEL-6.8.iso]
on: [/tmp/anvil_iso]
- Verifying they mounted.
- Verifying that everything we're about to copy is under 4 GiB for 'vfat'
compatibility.
- Copying the source ISO contents to the USB device.
- Protecting the USB drive in case 'striker-usb-insert' is set to force-initialize.
- Copying the source ISO to the USB drive. This might take a bit, please be
patient!
- Copying the 'syslinux' files into place.
- Cleaning up, please wait while the USB drive is finalized!
If the OS cached data being written to the USB, this might take a bit.
- Unmounting: [/tmp/anvil_iso]
- Removing the temporary mount point: [/tmp/anvil_iso]
- Unmounting: [/tmp/anvil_usb]
- Removing the temporary mount point: [/tmp/anvil_usb]
Done!
Plug the USB drive into the machine you wish to make a Striker dashboard. Press
the key for you system to manually select a boot device (usually <F10> or
<F12>) and choose this USB drive. Select the appropriate Striker number from
the menu.
NOTE: The Install performed by this USB drive is fully automated, once started.
Any data on the target machine will be erased without further warning!
Have fun!
|
Note: Don't worry about the warning. This will only be needed once. |
All done!
Building The First Striker Dashboard
The first dashboard will be booted off of either the DVD or USB drive. How exactly you do this will depend on your hardware, so please consult your machine's service manual for instructions on how to choose a temporary boot device.
Hardware Requirements
The Striker dashboard has fairly modest system requirements. The only hard requirement is that the machine can run RHEL or CentOS 6 and that it has two network interfaces (wireless is NOT supported).
The recommended minimum configuration is:
- Intel Core i5 v5 (or AMD equivalent) or newer CPU
- 8 GiB of RAM
- 128 GiB SSD
- 4x 1 Gbps NICs
The above specs will provide plenty of performance for hosting the ScanCore database as well as provide network redundancy on both the Back-Channel Network and the Intranet-Facing Network.
Stage-1 Striker Install
Boot from the USB drive or DVD (ISO). Press the key to select a temporary boot device and choose the boot device you created.
Once you select the boot device, you will see the Striker boot menu.
|
Warning: Once selected, the rest of the stage-1 install is automated. Any existing data on the machine will be erased! |
We're building "Striker 01", so that is what we'll choose.
The rest of the install is automated.
When the stage-1 install is finished, you will be presented with a standard RHEL login.
|
Note: The user name is 'root' and the password is 'Initial1'. This is the case for all stage-1 installed dashboards and nodes. |
That's all for stage-1!
Stage-2 Striker Install
There are several ways to customise Striker for your environment. Below is a couple of examples with a link to the complete list.
striker-installer Switches
|
Note: There is an example install call on all Striker dashboards at '/root/striker-installer.example'. You can edit this file and then run it directly with 'sh /root/striker-installer.example' to further simplify the stage-2 install. |
Example striker-install Invocations
|
Note: This is a standard bash call, so please be sure to quote anything with spaces and to escape special characters like !. |
|
Warning: The --host-uuid <uuid> MUST be unique across dashboards. Please don't directly copy and past without changing the UUID (use uuidgen to create one for you). |
The most common install will look like this:
./striker-installer \
-c "Alteeve's Niche! Inc." \
-n "an-striker01.alteeve.ca" \
-u "admin:super secret password" \
-i 10.255.4.1/16,dg=10.255.255.254,dns1=8.8.8.8,dns2=8.8.4.4 \
-b 10.20.4.1/16 \
-p 10.20.10.200:10.20.10.209 \
--peer-dashboard hostname=an-striker02.alteeve.ca,bcn_ip=10.20.4.2 \
--host-uuid 32e47561-5840-4c6a-9732-2627efcd0af2 \
--router-mode \
--rhn "rhn_admin:rhn_secret"
This will configure the dashboard as the first striker using the standard BCN address '10.20.4.1' with a '255.255.0.0' subnet mask. In this example, the internet-facing network is '10.255.0.0/16', so we set the IFN address '10.255.4.1/16' and '10.255.255.254' gateway using Google's open DNS servers. The host name is set to 'an-striker01.alteeve.ca', the administrative user (and striker web user) is 'admin' and the nice long password of 'super secret password'.
We want this Striker to stay in sync with its peer, 'an-striker02.alteeve.ca', so we tell this machine where to find it. Don't worry that the peer doesn't exist yet. When it is built, they will sync when they find each other for the first time later.
We want to use this as an "Install Target", so we set a few extra options. We tell it to route BCN traffic to the internet (when "Install Target" is activated only) and we tell this machine to offer up IP addresses from '10.20.10.200' to '10.20.10.209'. These are only needed for a short time when a machine (node or dashboard) boots without an operating system (or when you are about to reload the OS).
This is a RHEL install proper, so the Red Hat user name 'rhn_user' and password are set so that the machine is registered and the needed subscriptions added. Obviously, there is no need to use --rhn when you're installing based on CentOS.
Later, when we're ready to do stage-2 on the second dashboard, we would use:
./striker-installer \
-c "Alteeve's Niche! Inc." \
-n "an-striker01.alteeve.ca" \
-u "admin:super secret password" \
-i 10.255.4.2/16,dg=10.255.255.254,dns1=8.8.8.8,dns2=8.8.4.4 \
-b 10.20.4.2/16 \
-p 10.20.10.210:10.20.10.219 \
--peer-dashboard hostname=an-striker01.alteeve.ca,bcn_ip=10.20.4.1 \
--host-uuid c63dda20-accb-4cc5-a2ff-8fc5be8d953b \
--router-mode \
--rhn "rhn_admin:rhn_secret"
The main differences are the final octet of the BCN and IFN addresses are '2', the hostname is 'an-striker02', the peer information points to Striker 1 and the lease range is from '10.20.10.210' to '10.20.10.219'.
Running striker-installer
For this document, we are using KVM virtual servers (the same foundation used in the Anvil! itself). When run on a workstation, it uses the IFN '192.168.122.0/24', so we'll adapt our 'striker-installer' to suit. We'll do this by editing the provides 'striker-installer.example'.
vim striker-installer.example
./striker-installer \
-c "Alteeve's Niche! Inc." \
-n "an-striker01.alteeve.ca" \
-u "admin:super secret password" \
-i 192.168.122.251/24,dg=192.168.122.1,dns1=8.8.8.8,dns2=8.8.4.4 \
-b 10.20.4.1/16 \
-p 10.20.10.200:10.20.10.209 \
--peer-dashboard hostname=an-striker02.alteeve.ca,bcn_ip=10.20.4.2 \
--host-uuid 32e47561-5840-4c6a-9732-2627efcd0af2 \
--router-mode \
--rhn "rhn_admin:rhn_secret"
|
Note: For this tutorial, the admin password is 'super secret password'. Please use a different password in your environment! |
With that edited, we can start the install!
sh /root/striker-installer.example
If your striker dashboard has a Siig, and if you accepted the ASIX user license when you created the Anvil! ISO, the drivers will be compiled and loaded, the interface will be started and if available, an IP address will be acquired. Many smaller Striker dashboards are built on Intel NUCs with these Siig adapters as their IFN interface, so this behaviour makes sure everything is up and running before the install starts. If your machine does not have a Siig adapter, this step is skipped.
The install starts by checking for an Internet connection. If a connection is found and if the base OS is RHEL and if --rhn was used, the machine will register with Red Hat.
The beginning of the install will look something like this
##############################################################################
# ___ _ _ _ The Anvil! Dashboard #
# / __| |_ _ _(_) |_____ _ _ -=] Installer #
# \__ \ _| '_| | / / -_) '_| #
# |___/\__|_| |_|_\_\___|_| #
# https://alteeve.ca/w/Striker #
##############################################################################
Sanity-checking command line switches:
Done.
Checking the operating system to ensure it is compatible.
- We're on a RHEL (based) OS, good. Checking version.
- Looks good! You're on: [6.8]
- This OS is RHEL proper.
Done.
Checking for an Internet connection...
- Internet access detected.
Done.
RHN credentials given. Attempting to register now.
- [ Note ] Please be patient, this might take a minute...
- Registration was successful.
- Adding 'Optional' channel...
- Output: [Repository 'rhel-6-server-optional-rpms' is enabled for this system.]
- 'Optional' channel added successfully.
Done.
Backing up some network related system files.
- The backup directory: [/root/anvil] doesn't exist, creting it.
- Backup directory successfully created.
- Backing up: [/etc/udev/rules.d/70-persistent-net.rules]
- It exists, backing it up.
- Copying: [/etc/udev/rules.d/70-persistent-net.rules] to: [/root/anvil/]
- Backing up: [/etc/sysconfig/network-scripts]
- Copying: [/etc/sysconfig/network-scripts] to: [/root/anvil/]
- Backing up: [/etc/rc.local]
- It exists, backing it up.
- Copying: [/etc/rc.local] to: [/root/anvil/]
Done.
Checking if we need to freeze NetworkManager on the active interface.
- NetworkManager isn't running, freeze not needed.
Done
Making sure all network interfaces are up.
- The network interface: [eth1] is down. It must be started for the next stage.
- Checking if: [/etc/sysconfig/network-scripts/ifcfg-eth1] exists.
- Config file exists, changing BOOTPROTO to 'none'.
- Attempting to bring up: [eth1]...
- Checking to see if it is up now.
- The interface: [eth1] is now up!
- The network interface: [eth2] is down. It must be started for the next stage.
- Checking if: [/etc/sysconfig/network-scripts/ifcfg-eth2] exists.
- Config file exists, changing BOOTPROTO to 'none'.
- Attempting to bring up: [eth2]...
- Checking to see if it is up now.
- The interface: [eth2] is now up!
- The network interface: [eth3] is down. It must be started for the next stage.
- Checking if: [/etc/sysconfig/network-scripts/ifcfg-eth3] exists.
- Config file exists, changing BOOTPROTO to 'none'.
- Attempting to bring up: [eth3]...
- Checking to see if it is up now.
- The interface: [eth3] is now up!
Done.
Mapping the Network
There is no way for a program to know that a given network interface is going to be used for a particular task. To handle this in a user-friendly way, the installer will ask you to unplug each cable, wait a moment, and then plug it back in. The installer can see which interface loses a connection and determine which interface you manipulated.
This mapping is the last step before the automated portion takes over.
|
Note: Striker dashboards with four interfaces will have redundant connections to the BCN and IFN. Larger installs using proper server-grade equipment should have four interfaces (and redundant power) for additional resiliency. It is not required, as the two Striker dashboards are inherently redundant for each other. |
When two interfaces are found, the mapping order will be:
- "Back-Channel Network - Link 1"
- "Internet-Facing Network - Link 1"
When four interfaces are found, the mapping order will be:
- "Back-Channel Network - Link 1"
- "Back-Channel Network - Link 2"
- "Internet-Facing Network - Link 1"
- "Internet-Facing Network - Link 2"
Lets see what this looks like with four interfaces
-=] Configuring network to enable access to Anvil! systems.
- Beginning NIC identification...
- Please unplug the interface you want to make:
[Back-Channel Network, Link 1]
Unplug the interface you want to make BCN link 1.
- NIC with MAC: [52:54:00:71:20:fa] will become: [bcn_link1]
(it is currently: [eth2])
- Please plug in all network cables to proceed.
Plug it back in and unplug the interface you want to make BCN link 2.
- Please unplug the interface you want to make:
[Back-Channel Network, Link 2]
Plug it back in and unplug the interface you want to make IFN link 1.
- NIC with MAC: [52:54:00:3d:bc:57] will become: [bcn_link2]
(it is currently: [eth3])
- Please plug in all network cables to proceed.
- Please unplug the interface you want to make:
[Internet-Facing Network, Link 1]
Plug it back in and unplug the interface you want to make IFN link 2.
- NIC with MAC: [52:54:00:d3:a9:0f] will become: [ifn_link1]
(it is currently: [eth0])
- Please plug in all network cables to proceed.
- Please unplug the interface you want to make:
[Internet-Facing Network, Link 2]
Finally, plug it back in.
You will now see a summary of what will be done.
- NIC with MAC: [52:54:00:55:c0:6e] will become: [ifn_link2]
(it is currently: [eth1])
- Please plug in all network cables to proceed.
Done.
Here is what you selected:
- Interface: [52:54:00:71:20:FA], currently named: [eth2],
will be renamed to: [bcn_link1]
- Interface: [52:54:00:3D:BC:57], currently named: [eth3],
will be renamed to: [bcn_link2]
- Interface: [52:54:00:D3:A9:0F], currently named: [eth0],
will be renamed to: [ifn_link1]
- Interface: [52:54:00:55:C0:6E], currently named: [eth1],
will be renamed to: [ifn_link2]
The Back-Channel Network interface will be set to:
- IP: [10.20.4.1]
- Netmask: [255.255.0.0]
The Internet-Facing Network interface will be set to:
- IP: [192.168.122.251]
- Netmask: [255.255.255.0]
- Gateway: [192.168.122.1]
- DNS1: [8.8.8.8]
- DNS2: [8.8.4.4]
Shall I proceed? [Y/n]
If you are happy, press '<enter>' to start the install. If you made a mistake, type 'n' + '<enter>' and the install will exit. Simply restart the install and try again until you are happy.
Stage-2 Install Completes
From here on out, the rest of the install is automated. It might take a while, so this is a good time to go grab a $drink.
When it is done, it will reboot and you will see the graphical login screen!
You should now be able to access the Striker web interface from any device on the BCN of IFN with a web browser.
Enter the dashboard's IP address into your browser and you should see the login prompt.
Login using the user name and password you specified during the stage-2 install. In our case, we stuck with the default user 'admin'.
Voila! You have your first Striker dashboard built. If all went well, you no longer need the install media. Future installs can be done over the network from this Striker.
Enabling 'Install Target'
Now that we have the first dashboard built, we can build the second using it as a PXE server.
From the Striker web interface, select ''.
|
Warning: Enabling '' causes a DHCP server to start running on Striker’s BCN. If you haven't isolated the BCN from the IFN. This could cause normal clients to get their IP from Striker, which wouldn't work in most cases. |
Read and then confirm:
Now you can boot bare-iron machines using their network interface!
Done!
Building The Second Striker From The First
As before, building a Striker dashboard is a two-stage process. The difference this time is that we don't use the ISO (or USB drive) we made before. Now we're going to install off of the first dashboard directly.
Second Striker Stage-1 Install
Boot your second dashboard and manually select the boot device. How exactly you do this will depend on the vendor of your machine.
|
Note: If your machine has multiple network-bootable devices, you may need to experiment to find which one is connected to the BCN. |
Select "New Striker 02 dashboard", and the rest of the stage-1 install will complete automatically.
When done, you will see the same default login screen as you did for the first Striker dashboard install.
Second Striker Stage-2 Install
As before, the login user for stage-1 is 'root' and the password is 'Initial1'.
Once you log in, edit '/root/striker-installer.example', edit it to suit your needs and then run it. The rest of the install proceeds exactly as it did for the first Striker install above.
Here is our '/root/striker-installer.example'.
|
Warning: The --host-uuid <uuid> MUST be unique across dashboards. Please don't directly copy and past without changing the UUID (use uuidgen to create one for you). |
The most common install will look like this:
./striker-installer \
-c "Alteeve's Niche! Inc." \
-n "an-striker02.alteeve.ca" \
-u "admin:super secret password" \
-i 192.168.122.252/24,dg=192.168.122.1,dns1=8.8.8.8,dns2=8.8.4.4 \
-b 10.20.4.2/16 \
-p 10.20.10.210:10.20.10.219 \
--peer-dashboard hostname=an-striker01.alteeve.ca,bcn_ip=10.20.4.1 \
--host-uuid a9a9cdc5-0c10-4ee1-9102-ecba16f75e09 \
--router-mode \
--rhn "rhn_admin:rhn_Initial1"
With that edited, we can run the file as a script and perform our stage-2 install.
sh /root/striker-installer.example
Map the network interfaces when prompted and the rest of the stage-2 install will be completed automatically. When it is done, it will reboot and present you with the same login screen as before.
Done!
Building The First Anvil!
Building an Anvil! node pair is also a 2-stage process. The main difference is that stage-2 is controlled by an 'Install Manifest' that we run on a Striker dashboard. Striker then uses that manifest as a reference to control how the nodes are partitioned, named, and configured.
The benefit of this approach is that the manifest is recorded and can be used in the future to rebuild a node that was damaged or destroyed.
Node Stage-1 Install
Running the stage-1 install for nodes is identical to how it was run for the second Striker.
Boot the nodes and select a temporary boot device.
|
Note: Nodes will have six network bootable interfaces, so you might need to experiment to find which ones are on the BCN. Once you find them, it is a good idea to make note of the adapter's ID. It will save you having to hunt around if you need to rebuild or replace the node in the future. |
Select "New Anvil! Node 01", and the rest of the stage-1 install will complete automatically.
| an-a03n01 | an-a03n02 |
|---|---|
|
Note: The node install starts by "zero'ing out" the first 100 GiB of the disk. This causes the stage-1 install to appear to hang for a while. Please be patient. |
When done, you will see the same default login screen as you did for the Striker dashboards.
| an-a03n01 | an-a03n02 |
|---|---|
 |
 |
There is no need to log in this time, however. Make a note of the IP addresses that each node got. We want to use the BCN IP addresses, which are the '10.20.0.0/16' IPs (unless you changed the BCN subnet when you built your Striker dashboards).
In the example above, the IPs we care about are:
| an-a03n01 | an-a03n02 |
|---|---|
| 10.20.10.204 | 10.20.10.205 |
|
Note: The 'Install Target' feature is no longer needed. You can now disable it by clicking on ''. |
Stage-1 is done!
Creating An 'Install Manifest'
To create an 'Install Manifest', click on the '' button on Striker.
The 'Install Manifest' form is long, but most of it will be auto-filled for you.
The main part to be aware of are the eight fields at the top.
| Field | What it does | What it should be set to | Restrictions |
|---|---|---|---|
| Anvil! Prefix | This prefix is used by people with multiple Anvil! systems and can help group Anvil! pairs by client, department or location. | This is pre-set using the Dashboard's prefix and likely doesn't need to change. | Only letters or numbers are allowed. Generally this is 2 or 3 characters, but there is no hard limit on it's length. |
| Sequence Number | Provides a differentiation between Anvil!' systems with the same prefix. This sequence number will be used to preset IP addresses and PDU outlet numbers. | a simple digit. | There is no hard limit, but numbers over 24 will likely require manual setting of IPs. |
| Domain Name | Sets the domain name portion of the nodes' hostnames and foundation pack equipment. | Generally, this should be set to your organisation's host name (or division, client, etc). | This must be a standard domain name comprising letters, numbers and hyphens. |
| Anvil! Password | Sets the node's 'root' and 'ricci' passwords. | Something kept private! | Note: The password set is echoed back to you and must be stored in plain text in the ScanCore database in order to interact with the nodes. Don't use the same password you use elsewhere and restrict access to the Striker dashboards! |
| BCN Subnet | The private management network used for inter-node, dashboard to node and node to foundation pack communication. | 10.20.0.0/16, except when that would conflict with existing networks. | A valid IPv4 subnet. |
| SN Subnet | The private storage network used for inter-node storage replication. | 10.10.0.0/16, except when that would conflict with existing networks. | A valid IPv4 subnet. |
| IFN Subnet | The public network used to communicate with your network equipment and clients. | Free IPv4 addresses available on your network. The form will try to select sane default IPs, though you will want to verify the selected IPs are available. | A valid IPv4 subnet. |
| Media Library Size | How much space to allocate for ISOs (images of CD and DVD disks) used to install servers or "put into" a server's (virtual) optical drive. | Between 10 and 40 GiB is sufficient for most users. | Start small, the size can be extended later if needed. It can not be shrunk. |
In this tutorial, we will be creating our third Anvil! system, and we'll stick with the default 'an' prefix and 'alteeve.ca' domain name. Our IFN subnet is '192.168.122.0/24' and we'll start with a modest 10 GiB media library size.
With that set, click on '' and the form will do its best to set the rest of the form's details for you.
Please review all the fields the first time you create a manifest. Each field is explained and there is a link on the right for all fields that will take you to our wiki and explain each field in much more detail, if needed.
The main fields to check are:
- Are the IFN IP addresses of the nodes right?
- Are the IP addresses of the foundation pack devices and Striker dashboards right?
- Are the PDU outlet port numbers correct?
|
Warning: It is critical that the PDUs and their outlet ports map properly to the nodes and their PSUs. Double and triple check these values! |
Once you are happy with the fields, click on '' to view a summary of the manifest data.
Careful! Be sure that the summary data is as you expect it to be. Once generated, this manifest will control the Anvil! node pair construction and regeneration should a node fail. It is very important that the data is correct.
If you are happy, click '' on the summary and the 'Install Manifest' will be created and saved.
The 'Install Manifest' is saved in the ScanCore database. As such, it is immediately sync'ed to other dashboards and will remain in Striker until you delete it.
All done!
Anvil! Node Pair Stage-2 Install
Now that the manifest has been created and both nodes have completed their stage-1 installs, we're ready to build the Anvil! node pair!
At this stage, there is only one manifest to choose. So click on ''.
The manifest always defaults to each node's BCN IP address and the recorded password.
In our case, both nodes just finished their stage-1 install, so they will have the temporary IPs we noted earlier and both will use the default stage-1 password 'Initial1'.
Recall that the temporary IPs of the two newly built nodes were:
| an-a03n01 | an-a03n02 |
|---|---|
| 10.20.10.204 | 10.20.10.205 |
So we will update the login fields.
|
Warning: Be sure to review the manifest data! This is particularly true when you have multiple manifests. Don't run the wrong one by accident. |
When you're ready, click on ''.
Anvil! Node Pair Stage-2 Network Mapping
Once the run begins, it will verify that it can talk to both nodes, do some sanity checks and then begin the network mapping process. This is virtually identical to what you did when you mapped the dashboard's network, except this time the prompts are in the browser.
|
Note: When you pull the network cable that Striker is using to talk to the node, you will not see the prompt to plug the cable back in. This is normal. Keep the cable unplugged for about five seconds, plug it back in and then wait. Striker will catch up and move on normally a few seconds later. |
If you can't see the screen when you unplug the cables, don't worry. The order of the prompts is always the same. If you wait five seconds between each unplug and another five seconds after plugging the cables back in, you will be able to reliably map without seeing the screen. Do wait a minute between node 1 and 2 though so that node 2 has time to prepare for the remap.
The map order is always;
- . Back-Channel Network, Link 1
- . Back-Channel Network, Link 2
- . Storage Network, Link 1
- . Storage Network, Link 2
- . Internet-Facing Network, Link 1
- . Internet-Facing Network, Link 2
Once you've mapped both nodes and are happy with the results, you're ready to proceed.
If your nodes are built on RHEL proper, you will see the fields for registering your nodes with Red Hat, as you can see above. If you built on CentOS, those fields will be absent.
|
Note: If you don't register with Red Hat and you are using RHEL, the nodes will not be updated during the install. |
If you made a mistake mapping the network, just keep going until all the interfaces have been unplugged and plugged back in. You can start over by clicking on ''.
Anvil! Node Pair Stage-2 Under Way
|
Warning: Do not browse away once the install has started! If you do for some reason, reboot both nodes, see what IPs they have and re-run the install manifest. |
|
Note: Once you click on '', the network mapping is recorded. If you run the manifest again against the same hardware nodes, you won't have to map the network again, unless you specifically choose to. |
If you are happy with the mapping, the click on '' to begin.
Once the install starts, you will have about 20 to 30 minutes to wait.
|
Note: If the install fails for any reason, it tries to tell you why it failed. That may not be useful enough, however. Details can be viewed by reading '/var/log/striker.log' on the Striker dashboard that was running the manifest. Once you think you've fixed the problem, you can restart by clicking on the '' button. Please use this button! If the error was hit after the IP addresses changed, using your browser's 'reload' button might tell the browser to connect to the old address. |
After some time, possibly quite some time depending on your nodes, the install will finish.
Click on '' at the bottom to record the new Striker in the database.
Adding The New Anvil! To The Database
The Anvil! is not automatically added because there are a few things you need to tell Striker.
There are two sections; The top section where you need to saw who owns the new Anvil! and a short description that will be displayed in the Anvil! selection list. The owner name and description are for your benefit and you can set them to whatever makes sense to you. The 'owner' might well be a department, site name and so on.
The second section is the information needed to send email alerts. If you don't plan to use email-based alerts, simply clear the 'Login Name' field. If you do want to use email alerts, however, please fill out the information needed to connect to your SMTP server.
|
Note: Anvil! nodes run a local copy of postfix that queues and sends emails. If your outgoing email server supports encrypted connections, then alerts from the nodes to the mail server will be securely delivered. |
If you have added an Anvil! system before, then you will be able to select existing owners and outgoing mail servers, saving the need to re-enter the information.
With the form filled out, click on ''.
Once saved, you will see a 'success' message along with two buttons; One for managing alert recipients and one to start working with the new Anvil! right away.
When you saved the new Anvil!, you told the nodes how to send email alerts, but not were to send them. When you click on the button for alert recipients, you get a chance to define who will receive alerts, and what level of alerts they want to receive. We'll cover that menu in a moment.
When this is a new Anvil! system, click on ' to manage alert recipients. This will open a new tab in your browser with the alert recipient menu. Then click on ' to start using it' to view your newly built Anvil! system
Setting Up Alert Recipients
Alert recipients can be one of two types; Alerts sent by email and alerts written to a local file.
The first field, 'Target', determines what the recipient type is. If it is an email address, then the recipient will be sent alerts over email. Otherwise, it is assumed that the notification target is a file. In that case, alerts will be written to '/var/log/$filename' on the machine generating the alert.
Generally speaking, most users will want to send alerts via email. The main users who will use the file-type alert target are users whose Anvil! system is not connected to the public Internet. If this is your case, then you can periodically pick up the file for analysis. Be sure to delete or empty the file when you pick it up, if you want to keep its size small.
The second field, 'Recipient Name', is mainly used for email notification targets. This is used when sending to email and is used in the email's 'To' field.
If you have multiple languages installed, then you can select the recipient's language.
The second field, 'Recipient Name', is mainly used for email notification targets. This is used when sending to email and is used in the email's 'To' field.
If you have multiple languages installed, then you can select the recipient's language.
The 'Alert Level' is a selection box that determines what alert level this recipient wants, if at all, when new Anvil! systems are added.
The 'Measurements' lets you choose between sending measurements to the recipient in metric or imperial measurements.
The 'Notes' field is purely for your benefit to store information about the alert recipient. Use it however you want, if at all.
Lastly, there is a section to select the alert level the recipient for each existing Anvil! system. We just added the first one, so only it is shown. Select the desired alert level, and you're done!
When you're happy with your entry, click on ''.
Voila! You'll see the drop-down box at the top. If you want to change anything, go for it and then click '' again.
You can close the tab now.
Using Your New Anvil! System
When you load an Anvil! system, there will be a delay while the current state of the Anvil! is examined.
After a moment, the main Anvil! menu page will be displayed.
That's it, you're done!
Building The First Server
Building a server on an Anvil! is pretty close to installing an operating system on traditional hardware. The only difference, of course, is that there is no drive to put a physical disc into. So before we can build the first server, we need an operating system disc image (called an ISO).
Striker uses a library to upload and store install media, driver discs or any other "CD" or "DVD" you might want to use. It is called the 'Media Library", and the library is specific to each Anvil! pair. So to access the library, load the Anvil! main page and look for the '' button at the bottom right.
| Any questions, feedback, advice, complaints or meanderings are welcome. | |||
| Alteeve's Niche! | Enterprise Support: Alteeve Support |
Community Support | |
| © Alteeve's Niche! Inc. 1997-2024 | Anvil! "Intelligent Availability®" Platform | ||
| legal stuff: All info is provided "As-Is". Do not use anything here unless you are willing and able to take responsibility for your own actions. | |||