Appboard/2.4/admin/clustering and failover - Revision history

imported>Jason.nicholls: /* Initial Preparation */

2014-08-07T05:19:12Z

Initial Preparation

← Older revision		Revision as of 05:19, 7 August 2014
Line 80:		Line 80:
	# Have two or more systems ready to be configured for clustering. Note it's possible to also use the existing system without having to re-install.		# Have two or more systems ready to be configured for clustering. Note it's possible to also use the existing system without having to re-install.
	# Have the AppBoard turnkey distribution and license files for each node.		# Have the AppBoard turnkey distribution and license files for each node.

			{{Note\|If re-establishing a cluster using the existing external database then '''all cluster nodes must be shutdown''' before proceeding.}}

	=== Setup Process ===		=== Setup Process ===

imported>Jason.nicholls: /* Setup Process */

2014-08-07T05:13:13Z

Setup Process

← Older revision		Revision as of 05:13, 7 August 2014
Line 88:		Line 88:
	# Configure AppBoard to use an external configuration database. Follow the instructions to use <tt>dbsetup</tt> on the [[appboard/2.4/admin/configuration_database\|Configuration Database]] page, but '''do not''' restore any archives or perform a dbreset.		# Configure AppBoard to use an external configuration database. Follow the instructions to use <tt>dbsetup</tt> on the [[appboard/2.4/admin/configuration_database\|Configuration Database]] page, but '''do not''' restore any archives or perform a dbreset.
	# Load the complete backup archive created in the initial preparation:		# Load the complete backup archive created in the initial preparation:
	#: <tt>portal Apply -jar ''archive.jar''</tt>		#: <tt>portal '''Apply''' -jar ''archive.jar''</tt>
	# Install the license file if not already - remember this is node specific.		# Install the license file if not already - remember this is node specific.
	# Start AppBoard. At this point you should have a working cluster of one node!		# Start AppBoard. At this point you should have a working cluster of one node!

imported>Jason.nicholls: /* Setup Process */

2014-08-07T05:12:17Z

Setup Process

← Older revision		Revision as of 05:12, 7 August 2014
Line 86:		Line 86:
	# If converting the existing deployment into a cluster deployment, first shutdown AppBoard.		# If converting the existing deployment into a cluster deployment, first shutdown AppBoard.
	# Otherwise, deploy the AppBoard turnkey and ensure a valid environment. See the [[appboard/2.4/admin/installation\|Installation]] documentation for more info.		# Otherwise, deploy the AppBoard turnkey and ensure a valid environment. See the [[appboard/2.4/admin/installation\|Installation]] documentation for more info.
			# Configure AppBoard to use an external configuration database. Follow the instructions to use <tt>dbsetup</tt> on the [[appboard/2.4/admin/configuration_database\|Configuration Database]] page, but '''do not''' restore any archives or perform a dbreset.
	# Load the complete backup archive created in the initial preparation:		# Load the complete backup archive created in the initial preparation:
	#: <tt>portal Apply -jar ''archive.jar''</tt>		#: <tt>portal Apply -jar ''archive.jar''</tt>
	# Configure AppBoard to use an external configuration database. Follow the instructions to use <tt>dbsetup</tt> on the [[appboard/2.4/admin/configuration_database\|Configuration Database]] page, but '''do not''' load any archives or perform a dbreset.
	# Install the license file if not already - remember this is node specific.		# Install the license file if not already - remember this is node specific.
	# Start AppBoard. At this point you should have a working cluster of one node!		# Start AppBoard. At this point you should have a working cluster of one node!

imported>Jason.nicholls: /* Initial Preparation */

2014-07-30T17:12:37Z

Initial Preparation

← Older revision		Revision as of 17:12, 30 July 2014
Line 75:		Line 75:
	=== Initial Preparation ===		=== Initial Preparation ===
	# Setup an external database for the shared configuration database, you will need the access details. Do not actually configure AppBoard to use the external database at this stage.		# Setup an external database for the shared configuration database, you will need the access details. Do not actually configure AppBoard to use the external database at this stage.
	# Set AppBoard to operate in redundancy mode. This is ~~enabling~~ the following setting in <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties</tt>:		# Set AppBoard to operate in redundancy mode. This is enabled using the following setting in <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties</tt>:
	#: <tt>hosts.redundant=true</tt>		#: <tt>hosts.redundant=true</tt>
	# Create a full backup archive of your existing system. Ensure this backup has been configured to include all custom filesystem assets. Refer to the [[appboard/2.4/admin/backup_and_recovery#Customizing_the_Export\|Backup & Recovery]] page for more information. It's recommended this archive also include all required JDBC database drivers, including the JDBC driver required for the external configuration database.		# Create a full backup archive of your existing system. Ensure this backup has been configured to include all custom filesystem assets. Refer to the [[appboard/2.4/admin/backup_and_recovery#Customizing_the_Export\|Backup & Recovery]] page for more information. It's recommended this archive also include all required JDBC database drivers, including the JDBC driver required for the external configuration database.

imported>Jason.nicholls: /* Per-Node Configuration & Assets */

2014-07-22T06:12:31Z

Per-Node Configuration & Assets

← Older revision		Revision as of 06:12, 22 July 2014
Line 45:		Line 45:
	* license file		* license file
	* configuration database connection details		* configuration database connection details
	* all other filesystem assets such as login pages, images for look and feel, images for visualizations, local data source files, and other miscellaneous pieces that have been built into the solution such as custom JSPs, CGIs, HTML/CSS/JS, etc...		* all other filesystem assets such as login pages, images for look and feel, images for visualizations, local data source files, enPortal PIM files, and other miscellaneous pieces that have been built into the solution such as custom JSPs, CGIs, HTML/CSS/JS, etc...

	The recommended approach, which also serves to ensure full-backups are made of the system, is to configure the [[appboard/2.4/admin/backup_and_recovery#Customizing_the_Export\|Backup export list]] to include all filesystem assets. Then when establishing, or updating a cluster, the archive can be used to maintain the filesystem components. Also, other custom approaches may also be suitable such as filesystem synchronization tools.		The recommended approach, which also serves to ensure full-backups are made of the system, is to configure the [[appboard/2.4/admin/backup_and_recovery#Customizing_the_Export\|Backup export list]] to include all filesystem assets. Then when establishing, or updating a cluster, the archive can be used to maintain the filesystem components. Also, other custom approaches may also be suitable such as filesystem synchronization tools.

imported>Jason.nicholls: /* Cluster Configuration */

2014-07-22T06:09:49Z

Cluster Configuration

← Older revision		Revision as of 06:09, 22 July 2014
Line 31:		Line 31:

	Also consider that establishing a new cluster and maintaining the cluster may have different approaches as outlined below.		Also consider that establishing a new cluster and maintaining the cluster may have different approaches as outlined below.


	=== Shared Configuration Database ===		=== Shared Configuration Database ===
Line 67:		Line 66:

	Some virtualization environments may offer their own layer of fault tolerance although this is usually targeted at reducing/eliminating the impact of hardware failure - e.g. VMware Fault Tolerance to transparently failover a guest from a failed physical host to a different physical host such that everything continues un-interrupted. This type of system is useful on it's own but may not be aware of application-level failures that can also occur.		Some virtualization environments may offer their own layer of fault tolerance although this is usually targeted at reducing/eliminating the impact of hardware failure - e.g. VMware Fault Tolerance to transparently failover a guest from a failed physical host to a different physical host such that everything continues un-interrupted. This type of system is useful on it's own but may not be aware of application-level failures that can also occur.


	== Establishing a Cluster ==		== Establishing a Cluster ==

imported>Jason.nicholls at 06:09, 22 July 2014

2014-07-22T06:09:20Z

← Older revision		Revision as of 06:09, 22 July 2014
Line 1:		Line 1:
	{{DISPLAYTITLE:Clustering & ~~High Availability~~}}		{{DISPLAYTITLE:Clustering & Failover}}
	[[Category:AppBoard 2.4]]		[[Category:AppBoard 2.4]]
	== Overview ==		== Overview ==

imported>Jason.nicholls at 06:05, 22 July 2014

2014-07-22T06:05:46Z

← Older revision		Revision as of 06:05, 22 July 2014
Line 64:		Line 64:

	=== Virtualized Environments ===		=== Virtualized Environments ===

	Whether running on the bare metal or within virtualized environments the clustering configuration remains the same.		Whether running on the bare metal or within virtualized environments the clustering configuration remains the same.

Line 77:		Line 76:

	=== Initial Preparation ===		=== Initial Preparation ===

	# Setup an external database for the shared configuration database, you will need the access details. Do not actually configure AppBoard to use the external database at this stage.		# Setup an external database for the shared configuration database, you will need the access details. Do not actually configure AppBoard to use the external database at this stage.
	# Set AppBoard to operate in redundancy mode. This is enabling the following setting in <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties</tt>:		# Set AppBoard to operate in redundancy mode. This is enabling the following setting in <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties</tt>:
Line 86:		Line 84:

	=== Setup Process ===		=== Setup Process ===

	The following applies to the '''primary node'''. Even in a purely load-balanced configuration pick one of the nodes as the primary for purposes of establishing the cluster:		The following applies to the '''primary node'''. Even in a purely load-balanced configuration pick one of the nodes as the primary for purposes of establishing the cluster:

Line 119:		Line 116:
	Additional verification of the whole cluster can be performed by logging into the separate nodes from different locations and viewing the [[appboard/2.4/builder/system_administration/manage_sessions\|Session Management]] system administration page and verifying that all sessions are visible regardless of the node logged into.		Additional verification of the whole cluster can be performed by logging into the separate nodes from different locations and viewing the [[appboard/2.4/builder/system_administration/manage_sessions\|Session Management]] system administration page and verifying that all sessions are visible regardless of the node logged into.

	=== Maintaining a Cluster ===		== Maintaining a Cluster ==

			=== Product Updates ===
			For full product updates a process similar to establishing a new cluster is required. A full archive should be performed. This should be tested in isolation with the new build to ensure there are no upgrade issues. If changes need to be made due to the upgrade then produce a new full archive on the new version of the product for use when establishing the cluster. As the entire cluster will need to be taken down, and re-established, this process will require some scheduled downtime to complete.

			In high-availability environments if scheduled downtime is not possible then another approach would be to take down one node, re-establish a new cluster with a different external configuration database, then failover all clients to the new node. Other nodes can then be re-established pointing to the new configuration database, and then update the load balancer configuration to bring all nods back online.

			For patch updates these are usually overlaid onto an existing install and do not modify configuration. This can be done in-place and typically just require the AppBoard server to be restarted.

			=== Content/Configuration Updates ===

			Content and provisioning changes made directly on the cluster are immediately available to all cluster nodes and nothing further needs to be done.

			This section covers updates that are made either in a separate development or staging environment that need to be moved to production. For this there are two approaches:

			# complete updates made by using full archives. This would essentially require re-establishment of the cluster with the shortcut that AppBoard is already installed, licensed, and the database configuration is in place.
			# AppBoard-only content updates. This refers to Stacks, Boards, Widgets, Data Collections, Data Sources, Session Variables, and Theme configuration - which can be exported in isolation of the system configuration and then imported and merged into another system. Refer to the [[appboard/2.4/builder/system_administration/import_export\|Import/Export Utility]] documentation. New content can be built on a development system, then exported and merged into production. As this is content configuration only, it only has to be imported onto a single node in the cluster and does not require any downtime.

imported>Jason.nicholls: /* Setup Process */

2014-07-22T05:47:13Z

Setup Process

← Older revision		Revision as of 05:47, 22 July 2014
Line 116:		Line 116:
	# Start AppBoard. At this point you should now have a cluster of two or more nodes!		# Start AppBoard. At this point you should now have a cluster of two or more nodes!
	# Verify this instance the same as the primary instance.		# Verify this instance the same as the primary instance.

			Additional verification of the whole cluster can be performed by logging into the separate nodes from different locations and viewing the [[appboard/2.4/builder/system_administration/manage_sessions\|Session Management]] system administration page and verifying that all sessions are visible regardless of the node logged into.

	=== Maintaining a Cluster ===		=== Maintaining a Cluster ===

imported>Jason.nicholls: /* Setup Process */

2014-07-22T05:43:18Z

Setup Process

← Older revision		Revision as of 05:43, 22 July 2014
Line 108:		Line 108:
	# Load the complete backup archive created in the initial preparation. Note this is '''different''' than for the primary node:		# Load the complete backup archive created in the initial preparation. Note this is '''different''' than for the primary node:
	#: <tt>portal '''FilesImport -skiplist apply''' -jar ''archive.jar''</tt>		#: <tt>portal '''FilesImport -skiplist apply''' -jar ''archive.jar''</tt>
	# Ensure configuration is not loaded on AppBoard startup by renaming the following files by adding <tt>.disabled</tt> to their filenames:		# Ensure database configuration is '''not''' loaded on AppBoard startup by renaming the following files by adding <tt>.disabled</tt> to their filenames:
	#* <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/server/load_*.txt</tt>		#* <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/server/load_*.txt</tt>
	#* <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/appboard/load_*.txt</tt>		#* <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/xmlroot/appboard/load_*.txt</tt>