bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restructured Config Folder

Browse Source
This commit is contained in:
Nicole Rappe
2024-02-05 20:21:46 -07:00
parent f0925bf109
commit 6506203f7f
13 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

135
Servers & Processes/Windows Server/Virtualization/Hyper-V/Failover Cluster/Deploy Failover Cluster Node.md Normal file
View File

@ -0,0 +1,135 @@
**Purpose**: Deploying a Windows Server Node into the Hyper-V Failover Cluster is an essential part of rebuilding and expanding the backbone of my homelab. The documentation below goes over the process of setting up a bare-metal host from scratch and integrating it into the Hyper-V Failover Cluster.
!!! note "Prerequisites"
This document assumes you are have installed and are running a bare-metal Hewlett-Packard Enterprise server running iLO (Integrated Lights Out) with the latest build of **Windows Server 2022 Datacenter (Desktop Experience)**. Windows will prompt you that your build is expired if it is too old.
Download the newest build ISO of Windows Server 2022 at the [Microsoft Evaluation Center](https://go.microsoft.com/fwlink/p/?linkid=2195686&clcid=0x409&culture=en-us&country=us)
!!! info "Assumption that Cluster Already Exists"
This document also assumes that you are adding an additional server node to an existing Hyper-V Failover Cluster. This document does not outline the exact process of setting up a Hyper-V Failover Cluster from-scratch, setting up a domain, DNS server, etc. Those are assumed to already exist in the environment.
## Preparation
### Enable Remote Desktop
The first thing you will want to do is get remote access via Remote Desktop. This will enable higher resolution, faster response times with the GUI, and the ability to transfer files to and from the server more easily.
- Connect to the server via the iLO Remote Console
- Login using your `Administrator` credentials you created during the operating system installation
- Open **Server Manager**
* Navigate to "Local Server"
* Under "Remote Management"
* Click on "Disabled"
* Un-check: "Allow Remote Connections to this Computer"
!!! warning "Disable NLA (Network Level Authentication)"
Ensure that "Allow Connections only from computers running Remote Desktop with Network Level Authentication" is un-checked. This is important because if you are running a Hyper-V Failover Cluster, if the domain controller(s) are not running, you may be effectively locked out from using Remote Desktop to access the failover cluster's nodes, forcing you to use iLO or a physical console into the server to log in and bootstrap the cluster's Guest VMs online.
This step can be disregarded if the domain controller(s) exist outside of the Hyper-V Failover Cluster.
- Locate the (*current*) DHCP-issued IP address of the server for Remote Desktop
* You will want to use Remote Desktop for the next stage of deployment to transfer an ISO file to the server
* Log into the server with Remote Desktop using the `Administrator` credentials you created when initially installing the operating system
* You can use `ipconfig /all` to locate the current DHCP-issued IP address
### Provision Server Role & Domain Join
You will want to rename the computer so it has the correct naming scheme before installing any server roles or domain joining it. The general naming convention is `MOON-NODE-<0#>`. Use a domain administrator credential for the join command when prompted. Restart the computer to finalize the changes.
**Increment the hostname number based on the existing servers in the cluster / homelab.**
``` powershell
# Rename the server
Rename-Computer MOON-NODE-01
# Domain-join the server
Add-Computer MOONGATE.local
# Install Hyper-V server role
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools
# Install the Failover Clustering feature
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
# Restart the server to apply all pending configurations
Restart-Computer
```
## Failover Cluster Configuration
### Configure Cluster SET Networking
You will need to start off by configuring a Switch Embedded Teaming (SET) team. This is the backbone that the server will use for all Guest VM traffic as well as remote-desktop access to the server node itself. You will need to rename the network adapters to make management easier.
- Navigate to "Network Connections" then "Change Adapter Options"
* Rename the network adapters with simpler names. e.g. (`Embedded LOM 1 Port 1` becomes `Port_1`)
* For the sake of demonstration, assume there are 4 NICs (`Port_1`, `Port_2`, `Port_3`, and `Port_4`)
!!! warning "10GbE Network Adapters"
Be sure to leave the dual 10GbE network adapters out of the renaming work. They will be used later with the iSCSI Initiator.
``` powershell
# Switch Embedded Teaming (SET) team
New-VMSwitch -Name Cluster_SET -NetAdapterName Port_1, Port_2, Port_3, Port_4 -EnableEmbeddedTeaming $true
```
### Configure Static IP Address
You may be booted out of the Remote Desktop session at this time due to how the network team changed the configuration. Leverage iLO to remotely access the server again to configure a static IP address on the new `vEthernet (Cluster_SET)` NIC using the following configuration. **While in the NIC Properties, disable IPv6.**
| IP ADDRESS | SUBNET MASK | GATEWAY | PRIMARY DNS | SECONDARY DNS |
| ----------- | ------------- | ----------- | ------------ | ------------- |
| 192.168.3.5 | 255.255.255.0 | 192.168.3.1 | 192.168.3.10 | 192.168.3.11 |
### Configure Static IP Addresses for 10GbE Networking
You will now want to set up the network adapters for the 10GbE iSCSI back-end. Configure both of the `Intel(R) Ethernet Controller x540-AT2` 10GbE NICs and change their IP addresses to match the table below. Rename the NICs to match a `NIC1` and `NIC2` naming scheme. Also disable IPv6.
!!! warning
Make sure that you test that each interface can ping their respective iSCSI target by performing a ping using the IP address in the "ISCSI PING IP" column of the table. If it fails to successfully ping, swap the IP addresses of the 10GbE NICs until it succeeds.
| IP Address | Subnet Mask | Gateway | Primary DNS | Secondary DNS | iSCSI Ping IP |
| --------------- | ------------- | ------------- | ------------ | ------------- | --------------- |
| 192.168.102.200 | 255.255.255.0 | <Leave Blank> | 192.168.3.10 | 192.168.3.11 | 192.168.102.100 |
| 192.168.104.200 | 255.255.255.0 | <Leave Blank> | 192.168.3.10 | 192.168.3.11 | 192.168.104.100 |
### Configure iSCSI Initiator to Connect to TrueNAS Core Server
At this point, now that we have verified that the 10GbE NICs can ping their respective iSCSI target server IP addresses, we can add them to the iSCSI Initiator in Server Manager which will allow us to mount the cluster storage for the Hyper-V Failover Cluster.
- Open **Server Manager**
* Click on the "Tools" dropdown menu
* Click on "iSCSI Initiator"
* You will be prompted to start the Microsoft iSCSI service. Click on "Yes" to proceed.
* Click on the "Discovery" tab
* Click the "Discover Portal" button
* Enter the IP addresses of the "iSCSI Ping IP(s)" from the previous section. Leave the port as "3260".
* Navigate to the [TrueNAS Core server](https://storage.cyberstrawberry.net) and add the "Initiator Name" seen on the "Configuration" tab to the `Sharing > iSCSI > Initiator Groups` > "Hyper-V Failover Cluster Hosts"
* Example Initiator Name: `iqn.1991-05.com.microsoft:moon-node-01.moongate.local`
* This is not explicitly documented at this time and is different from lab to lab in regards to the iSCSI implementation
* Click the "Targets" tab to go back to the main page
* Click the "Refresh" button to display available iSCSI Targets
* Click on the first iSCSI Target `failover-cluster-storage` then click the "Connect" button
* Check the "Enable Multi-Path" checkbox
* Click the "Advanced" button
* Click the "OK" button
* Repeat the connection process seen above for all remaining iSCSI Targets
* Close out of the iSCSI Initiator window
* Navigate to "Disk Management" to bring the iSCSI drives "Online"
## Initialize and Join to Existing Failover-Cluster
### Validate Server is Ready to Join Cluster
Now it is time to set up the Failover Cluster itself so we can join the server to the existing cluster.
- Open **Server Manager**
* Click on the "Tools" dropdown menu
* Click on "Failover Cluster Manager"
* Click the "Validate Configuration" button in the middle of the window that appears
* Click "Next"
* Enter Server Name: `MOON-NODE-01.moongate.local`
* Click the "Add" button, then "Next"
* Ensure "Run All Tests (Recommended)" is selected, then click "Next", then click "Next" to start.
### Join Server to Failover Cluster
* On the left-hand side, right-click on the "Failover Cluster Manager" in the tree
* Click on "Connect to Cluster"
* Enter `MOON-CLUSTER.moongate.local`
* Click "OK"
* Expand "MOON-CLUSTER.moongate.local" on the left-hand tree
* Right-click on "Nodes"
* Click "Add Node..."
* Click "Next"
* Enter Server Name: `MOON-NODE-01.moongate.local`
* Click the "Add" button, then "Next"
* Ensure that "Run Configuration Validation Tests" radio box is checked, then click "Next"
* Validate that the node was successfully added to the Hyper-V Failover Cluster
## Cleanup & Final Touches
### Activate Windows Server
You will need to change the edition from "**Windows Server 2022 Datacenter Evaluation**" to "**Windows Server 2022 Datacenter**". This will ensure that the server does not randomly reboot itself. If you have a license, you can install it now. Otherwise, you can force-activate using the [Changing Windows Edition](https://docs.cyberstrawberry.net/mkdocs-material/homelab/Windows%20Server/Change%20Windows%20Edition/) documentation.
### Run Windows Updates
Ensure that you run all available Windows Updates before delegating guest VM roles to the new server in the failover cluster. This ensures you are up-to-date before you become reliant on the server for production operations.

80
Servers & Processes/Windows Server/Virtualization/Hyper-V/Failover Cluster/Rebuild Failover Cluster Replication.md Normal file
View File

@ -0,0 +1,80 @@
**Purpose**: If you run an environment with multiple Hyper-V: Failover Clusters, for the purpose of Hyper-V: Failover Cluster Replication via a `Hyper-V Replica Broker` role installed on a host within the Failover Cluster, sometimes a GuestVM will fail to replicate itself to the replica cluster, and in those cases, it may not be able to recover on its own. This guide attempts to outline the process to rebuild replication for GuestVMs on a one-by-one basis.
!!! note "Assumptions"
This guide assumes you have two Hyper-V Failover Clusters, for the sake of the guide, we will refer to the Production cluster as `CLUSTER-01` and the Replication cluster as `CLUSTER-02`. This guide also assumes that Replication was set up beforehand, and does not include instructions on how to deploy a Replica Broker (at this time).
## Production Cluster - CLUSTER-01
### Locate the GuestVM
You need to start by locating the GuestVM in the Production cluster, CLUSTER-01. You will know you found the VM if the "Replication Health" is either `Unhealthy`, `Warning`, or `Critical`.
### Remove Replication from GuestVM
- Within a node of the Hyper-V: Failover Cluster Manager
- Right-Click the GuestVM
- Navigate to "**Replication > Remove Replication**"
- Confirm the removal by clicking the "**Yes**" button. You will know if it removed replication when the "Replication State" of the GuestVM is `Not enabled`
## Replication Cluster - CLUSTER-02
### Note the storage GUID of the GuestVM in the replication cluster
- Within a node of the replication cluster's Hyper-V: Failover Cluster Manager
- Right-Click the same GuestVM and click "Manage..." `This will open Hyper-V Manager`
- Right-Click the GuestVM and click "Settings..."
- Navigate to "**ISCSI Controller**"
- Click on one of the Virtual Disks attached to the replica VM, and note the full folder path for later. e.g. `C:\ClusterStorage\Volume1\HYPER-V REPLICA\VIRTUAL HARD DISKS\020C9A30-EB02-41F3-8D8B-3561C4521182`
!!! warning "Noting the GUID of the GuestVM"
You need to note the folder location so you have the GUID. Without the GUID, cleaning up the old storage associated with the GuestVM replica files will be much more difficult / time-consuming. Note it down somewhere safe, and reference it later in this guide.
### Delete the GuestVM from the Replication Cluster
Now that you have noted the GUID of the storage folder of the GuestVM, we can safely move onto removing the GuestVM from the replication cluster.
- Within a node of the replication cluster's Hyper-V: Failover Cluster Manager
- Right-Click the GuestVM
- Navigate to "**Replication > Remove Replication**"
- Confirm the removal by clicking the "**Yes**" button. You will know if it removed replication when the "Replication State" of the GuestVM is `Not enabled`
- Right-Click the GuestVM (again) `You will see that "Enable Replication" is an option now, indicating it was successfully removed.`
!!! note "Replica Checkpoint Merges"
When you removed replication, there may have been replication checkpoints that automatically try to merge together with a `Merge in Progress` status. Just let it finish before moving forward.
- Within the same node of the replication cluster's Hyper-V: Failover Cluster Manager `Switch back from Hyper-V Manager`
- Right-Click the GuestVM and click "**Remove**"
- Confirm the action by clicking the "**Yes**" button
### Delete the GuestVM manually from Hyper-V Manager on all replication cluster hosts
At this point in time, we need to remove the GuestVM from all of the servers in the cluster. Just because we removed it from the Hyper-V: Failover Cluster did not remove it from the cluster's nodes. We can automate part of this work by opening Hyper-V Manager on the same Failover Node we have been working on thus far, and from there we can connect the rest of the replication nodes to the manager to have one place to connect to all of the nodes, avoiding hopping between servers.
- Open Hyper-V Manager
- Right-Click "Hyper-V Manager" on the left-hand navigation menu
- Click "Connect to Server..."
- Type the names of every node in the replication cluster to connect to each of them, repeating the two steps above for every node
- Remove GuestVM from the node it appears on
- On one of the replication cluster nodes, we will see the GuestVM listed, we are going to Right-Click the GuestVM and select "**Delete**"
### Delete the GuestVM's replicated VHDX storage from replication ClusterStorage
Now we need to clean up the storage left behind by the replication cluster.
- Within a node of the replication cluster
- Navigate to `C:\ClusterStorage\Volume1\HYPER-V REPLICA\VIRTUAL HARD DISKS`
- Delete the entire GUID folder noted in the previous steps. `e.g. 020C9A30-EB02-41F3-8D8B-3561C4521182`
## Production Cluster - CLUSTER-01
### Re-Enable Replication on GuestVM in Cluster-01 (Production Cluster)
At this point, we have disabled replication for the GuestVM and cleaned up traces of it in the replication cluster. Now we need to re-enable replication on the GuestVM back in the production cluster.
- Within a node of the production Hyper-V: Failover Cluster Manager
- Right-Click the GuestVM
- Navigate to "**Replication > Enable Replication...**"
- Click "Next"
- For the "**Replica Server**", enter the name of the role of the Hyper-V Replica Broker role in the (replication cluster's) Failover Cluster. `e.g. CLUSTER-02-REPL`, then click "Next"
- Click the "Select Certificate" button, since the Broker was configured with Certificate-based authentication instead of Kerberos (in this example environment). It will prompt you to accept the certificate by clicking "OK". (e.g. `HV Replica Root CA`), then click "Next"
- Make sure every drive you want replicated is checked, then click "Next"
- Replication Frequency: `5 Minutes`, then click "Next"
- Additional Recovery Points: `Maintain only the latest recovery point`, then click "Next"
- Initial Replication Method: `Send initial copy over the network`
- Schedule Initial Replication: `Start replication immediately`
- Click "Next"
- Click "Finish"
!!! success "Replication Enabled"
If everything was successful, you will see a dialog box named "Enable replication for `<GuestVM>`" with a message similar to the following: "Replica virtual machine `<GuestVM>` was successfully created on the specified Replica server `<Node-in-Replication-Cluster>`.
At this point, you can click "Close" to finish the process. Under the GuestVM details, you will see "Replication State": `Initial Replication in Progress`.