Disaster Recovery Tasks - Revision history

Digimer: /* Protecting A Specific Server */

2023-11-16T02:58:44Z

Protecting A Specific Server

@@ Line 135: / Line 135: @@
 Now that the discussion on protocols is behind us, lets protect our example server, <span class="code">srv01-primary-dc</span>. For now, we'll use the default async ''short-throw'' protocol.
 <syntaxhighlight lang="bash">
 </syntaxhighlight>
 <syntaxhighlight lang="text">
 </syntaxhighlight>

Digimer: /* Linking a DR host to an Anvil! node */

2023-11-16T01:37:33Z

Linking a DR host to an Anvil! node

← Older revision		Revision as of 01:37, 16 November 2023
Line 81:		Line 81:

	Perfect, we can see that the DR host is linked (uuid: <span class="code">c764b512-ebb4-487f-a631-d0ea6c5d262b</span>).		Perfect, we can see that the DR host is linked (uuid: <span class="code">c764b512-ebb4-487f-a631-d0ea6c5d262b</span>).

			=== Adding Volume Groups to Storage Groups ===

			If the DR Host's storage differs from the node it's been linked to, it's unlikely that the volume group on the DR host will be connected automatically to a storage group on the node. If this is the case for you, please see:

			* [[Managing Storage Groups]]

	= Protecting a Server =		= Protecting a Server =

Digimer at 03:51, 15 November 2023

2023-11-15T03:51:07Z

← Older revision		Revision as of 03:51, 15 November 2023
Line 11:		Line 11:
	A DR host can be used by multiple Anvil! nodes, and multiple DR hosts can be used by a given Anvil! node. To support this, a "linkage" need to be created to connect a DR host to a subnode.		A DR host can be used by multiple Anvil! nodes, and multiple DR hosts can be used by a given Anvil! node. To support this, a "linkage" need to be created to connect a DR host to a subnode.

	You can see the current list of Anvil! nodes, DR hosts and servers using the <span class="code">anvil-manage-dr --~~list~~</span> command		You can see the current list of Anvil! nodes, DR hosts and servers using the <span class="code">anvil-manage-dr --show</span> command

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	anvil-manage-dr --~~list~~		anvil-manage-dr --show
	</syntaxhighlight>		</syntaxhighlight>
	<syntaxhighlight lang="text">		<syntaxhighlight lang="text">
Line 59:		Line 59:
	</syntaxhighlight>		</syntaxhighlight>

	We can verify this with <span class="code">--~~list~~</span>.		We can verify this with <span class="code">--show</span>.

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	anvil-manage-dr --~~list~~		anvil-manage-dr --show
	</syntaxhighlight>		</syntaxhighlight>
	<syntaxhighlight lang="text">		<syntaxhighlight lang="text">

Digimer: /* Asynchronous Replication */

2023-11-15T03:37:15Z

Asynchronous Replication

← Older revision		Revision as of 03:37, 15 November 2023
Line 111:		Line 111:

	{\| class="wikitable"		{\| class="wikitable"
	!style="white-space:nowrap; text-align:center;"\|~~async (aka: '~~Short-Throw')		!style="white-space:nowrap; text-align:center;"\|Short-Throw
	\|style="white-space:nowrap; text-align:left;"\|This is the default, and it uses the standard network transmit buffer		\|style="white-space:nowrap; text-align:left;"\|This is the default, and it uses the standard network transmit buffer
	\|-		\|-

Digimer: /* Asynchronous Replication */

2023-11-15T03:35:11Z

Asynchronous Replication

← Older revision		Revision as of 03:35, 15 November 2023
Line 111:		Line 111:

	{\| class="wikitable"		{\| class="wikitable"
	!style="white-space:nowrap; text-align:center;"\|Short-Throw		!style="white-space:nowrap; text-align:center;"\|async (aka: 'Short-Throw')
	\|style="white-space:nowrap; text-align:left;"\|This is the default, and it uses the standard network transmit buffer		\|style="white-space:nowrap; text-align:left;"\|This is the default, and it uses the standard network transmit buffer
	\|-		\|-

Digimer: /* Protecting a Server */

2023-11-15T03:34:36Z

Protecting a Server

← Older revision		Revision as of 03:34, 15 November 2023
Line 120:		Line 120:
	The reason there are two options is this;		The reason there are two options is this;

	If the rate disk writes bursts long enough to fill the transmit buffer, storage writes will slow until there is space on the buffer. In typical installs where DR is in a distant part of the same building, or in another building in the same campus, short-throw is generally fine. However, if the local storage is subject to long periods of burst writes, this could still overwhelm the local network transmit buffer.		If the rate disk writes bursts long enough to fill the transmit buffer, storage writes will slow until there is space on the buffer. In typical installs where DR is in a distant part of the same building, or in another building in the same campus, '''short-throw''' is generally fine. However, if the local storage is subject to long periods of burst writes, this could still overwhelm the local network transmit buffer.

	There are other options to deal with filled transmit buffer while still using short-throw, which will be discussed later in this article.		There are other options to deal with filled transmit buffer while still using short-throw, which will be discussed later in this article.

	For now, the key benefit of '''long-throw''' DR is that is uses a commercial product from our partner LINBIT called [https://linbit.com/drbd-proxy/ DRBD Proxy]. This add-on, in short, uses up to 1 [[GiB]] of system RAM as an extension of the kernel's TCP transmit buffer. This greatly increases the amount of buffered data before contention becomes a concern, albeit at the expense that the data on the DR host is allowed to fall further behind during periods of burst writes or low bandwidth.		For now, the key benefit of '''long-throw''' DR is that is uses a commercial product from our partner LINBIT called [https://linbit.com/drbd-proxy/ DRBD Proxy]. This add-on, in short, uses up to 1 [[GiB]] of system RAM as an extension of the kernel's TCP transmit buffer. This greatly increases the amount of buffered data before contention becomes a concern, albeit at the expense that the data on the DR host is allowed to fall further behind during periods of burst writes or low bandwidth.

			== Protecting A Specific Server ==

			Now that the discussion on protocols is behind us, lets protect our example server, <span class="code">srv01-primary-dc</span>. For now, we'll use the default async ''short-throw'' protocol.

			<syntaxhighlight lang="bash">
			</syntaxhighlight>
			<syntaxhighlight lang="text">
			</syntaxhighlight>

Digimer: /* Protecting a Server */

2023-11-15T03:28:56Z

Protecting a Server

← Older revision		Revision as of 03:28, 15 November 2023
Line 108:		Line 108:
	The Anvil! uses multiple volumes within a single replicated storage resource. What this means is that write ordering is maintained, even for servers with multiple (virtual) hard drives. In this way, write ordering is maintained. As such, data on the DR host, though it may have been allowed to fall back in time, will be consistent. The server on the DR host, on boot, will be able to replay file system journals, process database write-ahead logs, and take other actions to ensure data consistency, just as if a normal machine lost power and had to reboot.		The Anvil! uses multiple volumes within a single replicated storage resource. What this means is that write ordering is maintained, even for servers with multiple (virtual) hard drives. In this way, write ordering is maintained. As such, data on the DR host, though it may have been allowed to fall back in time, will be consistent. The server on the DR host, on boot, will be able to replay file system journals, process database write-ahead logs, and take other actions to ensure data consistency, just as if a normal machine lost power and had to reboot.

			In asynchronous replication, there are two options;

			{\| class="wikitable"
			!style="white-space:nowrap; text-align:center;"\|Short-Throw
			\|style="white-space:nowrap; text-align:left;"\|This is the default, and it uses the standard network transmit buffer
			\|-
			!style="white-space:nowrap; text-align:center;"\|Long-Throw
			\|style="white-space:nowrap; text-align:left;"\|This is a commercial option that uses system RAM as an extension to the built-in kernel transmit buffer, used for particularly high latency, low bandwidth networks.
			\|}

			The reason there are two options is this;

			If the rate disk writes bursts long enough to fill the transmit buffer, storage writes will slow until there is space on the buffer. In typical installs where DR is in a distant part of the same building, or in another building in the same campus, short-throw is generally fine. However, if the local storage is subject to long periods of burst writes, this could still overwhelm the local network transmit buffer.

			There are other options to deal with filled transmit buffer while still using short-throw, which will be discussed later in this article.

			For now, the key benefit of '''long-throw''' DR is that is uses a commercial product from our partner LINBIT called [https://linbit.com/drbd-proxy/ DRBD Proxy]. This add-on, in short, uses up to 1 [[GiB]] of system RAM as an extension of the kernel's TCP transmit buffer. This greatly increases the amount of buffered data before contention becomes a concern, albeit at the expense that the data on the DR host is allowed to fall further behind during periods of burst writes or low bandwidth.

Digimer at 01:19, 15 November 2023

2023-11-15T01:19:47Z

@@ Line 31: / Line 31: @@
 - Server name: [srv01-primary-dc] on Anvil! Node: [an-anvil-01]
 </syntaxhighlight>
 == Linking a DR host to an Anvil! node ==

Digimer: Created page with "{{howto_header}} {{Note|1=At this time, DR management is via the command line. DR management in the UI is planned.}} Disaster Recovery on M3 clusters provides a way to create a copy of a server on a remote "DR Host". These are machines that generally match the capabilities of the Anvil! node the server runs on, but that's not a requirement. Servers don't live migrate to the DR host, and the DR host itself is not a member of the subcluster. Simply speaking..."

2023-11-14T22:59:38Z

Created page with "{{howto_header}} {{Note|1=At this time, DR management is via the command line. DR management in the UI is planned.}} Disaster Recovery on M3 clusters provides a way to create a copy of a server on a remote "DR Host". These are machines that generally match the capabilities of the Anvil! node the server runs on, but that's not a requirement. Servers don't live migrate to the DR host, and the DR host itself is not a member of the subcluster. Simply speaking..."

Páàjì titun

{{howto_header}}

{{Note|1=At this time, DR management is via the command line. DR management in the UI is planned.}}

Disaster Recovery on [[M3]] clusters provides a way to create a copy of a server on a remote "[[DR Host]]". These are machines that generally match the capabilities of the [[Anvil!]] node the server runs on, but that's not a requirement.

Servers don't live migrate to the DR host, and the DR host itself is not a member of the subcluster. Simply speaking, the DR host has a copy of the server's virtual hard drive(s), and the [[hypervisor]] has the configuration needed to boot the server. If the production node is destroyed, you can boot the server on the DR host.

= Linking DR Hosts =

A DR host can be used by multiple Anvil! nodes, and multiple DR hosts can be used by a given Anvil! node. To support this, a "linkage" need to be created to connect a DR host to a subnode.

You can see the current list of Anvil! nodes, DR hosts and servers using the <span class="code">anvil-manage-dr --list</span> command

<syntaxhighlight lang="bash">
anvil-manage-dr --list
</syntaxhighlight>
<syntaxhighlight lang="text">
Anvil! Nodes
- Node Name: [an-anvil-01], Description: [Demonstration anvil node]
- No linked DR hosts yet.
- Node Name: [an-anvil-02], Description: [RX200 S8 Test Node]
- No linked DR hosts yet.
- Node Name: [an-anvil-04], Description: [Test Mixed-Hardware Anvil! Node]
- No linked DR hosts yet.

-=] DR Hosts
- Name: [an-a01dr01.alteeve.com]

-=] Servers
- Server name: [srv01-primary-dc] on Anvil! Node: [an-anvil-01]
</syntaxhighlight>

== Linking a DR host to an Anvil! node ==

<span class="code"></span>
<syntaxhighlight lang="bash">
</syntaxhighlight>
<syntaxhighlight lang="text">
</syntaxhighlight>

{{footer}}