Appboard/old/clustering and failover - Revision history

imported>Jason.nicholls: /* enPortal/Appboard Replication for Clustering */

2014-07-18T05:48:24Z

enPortal/Appboard Replication for Clustering

← Older revision		Revision as of 05:48, 18 July 2014
Line 88:		Line 88:
	##Transfer the generated archive to the primary server's box.		##Transfer the generated archive to the primary server's box.
	#Importing the archive to the primary server.		#Importing the archive to the primary server.
	##[[~~Database_Configuration~~\|Configure the primary server's database connectivity]] using the "portal dbsetup" command in ${TomcatHome}/bin directory.		##[[appboard/old/configuration_database\|Configure the primary server's database connectivity]] using the "portal dbsetup" command in ${TomcatHome}/bin directory.
	##In the primary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.		##In the primary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.
	#Synchronizing content between the primary and the secondary enPortal/AppBoard instances.		#Synchronizing content between the primary and the secondary enPortal/AppBoard instances.

imported>Jason.nicholls: /* See Also */

2014-07-17T18:24:55Z

imported>Jason.nicholls at 18:16, 17 July 2014

2014-07-17T18:16:18Z

← Older revision		Revision as of 18:16, 17 July 2014
Line 85:		Line 85:

	#Preparation work		#Preparation work
	##In the development instance of enPortal/AppBoard, create an archive from the dev environment by running the [[~~Filesexport~~\|filesexport]] command.		##In the development instance of enPortal/AppBoard, create an archive from the dev environment by running the [[appboard/old/filesexport\|filesexport]] command.
	##Transfer the generated archive to the primary server's box.		##Transfer the generated archive to the primary server's box.
	#Importing the archive to the primary server.		#Importing the archive to the primary server.
Line 91:		Line 91:
	##In the primary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.		##In the primary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.
	#Synchronizing content between the primary and the secondary enPortal/AppBoard instances.		#Synchronizing content between the primary and the secondary enPortal/AppBoard instances.
	##In the primary server, create an archive by running the [[~~Filesexport~~\|filesexport]] command.		##In the primary server, create an archive by running the [[appboard/old/filesexport\|filesexport]] command.
	##Transfer the generated archive to the secondary server's box.		##Transfer the generated archive to the secondary server's box.
	##Validate the secondary server's database connectivity using the "portal dbsetup" command in ${TomcatHome}/bin directory.		##Validate the secondary server's database connectivity using the "portal dbsetup" command in ${TomcatHome}/bin directory.
Line 102:		Line 102:

	Notes:		Notes:
	*To verify that the above process is complete and worked correctly, you must do a full file comparison of the dev, primary, and secondary file systems to confirm that they are mirrored properly. If any custom files from the dev or primary system are missing from the secondary system, then you must modify the configuration of the filesexport command to include the additional customization files that did not get archived. For more information on this, see the [[~~Filesexport~~\|filesexport]] page.		*To verify that the above process is complete and worked correctly, you must do a full file comparison of the dev, primary, and secondary file systems to confirm that they are mirrored properly. If any custom files from the dev or primary system are missing from the secondary system, then you must modify the configuration of the filesexport command to include the additional customization files that did not get archived. For more information on this, see the [[appboard/old/filesexport\|filesexport]] page.
	*The database connector replication will occur automatically by the process above, because the database connection settings are stored in the file: persist.properites. Each time an enPortal/AppBoard instance is started, any load files in /server/webapps/enportal/WEB-INF/xmlroot/server/ which do not have the extension ".disabled" will be executed and the default XML content will be loaded into the database. Once the default content has been initially loaded into the database, you can remove the load files from the other instances before starting them, to prevent the XML content from being auto-loaded again into the database when that instance is started. This step would only be necessary if a server node has a new installation which is being started for the first time. The load files to remove are the following:		*The database connector replication will occur automatically by the process above, because the database connection settings are stored in the file: persist.properites. Each time an enPortal/AppBoard instance is started, any load files in /server/webapps/enportal/WEB-INF/xmlroot/server/ which do not have the extension ".disabled" will be executed and the default XML content will be loaded into the database. Once the default content has been initially loaded into the database, you can remove the load files from the other instances before starting them, to prevent the XML content from being auto-loaded again into the database when that instance is started. This step would only be necessary if a server node has a new installation which is being started for the first time. The load files to remove are the following:
	**load_reloadContent.txt		**load_reloadContent.txt

imported>Jason.nicholls at 05:32, 17 July 2014

2014-07-17T05:32:47Z

← Older revision		Revision as of 05:32, 17 July 2014
Line 1:		Line 1:
	{{DISPLAYTITLE:Clustering & Failover}}		{{DISPLAYTITLE:Clustering & Failover}}
			[[Category:AppBoard old]]
	== Architecture ==		== Architecture ==

imported>Jason.nicholls: moved Clustering And Failover to appboard/old/clustering and failover

2014-07-17T05:31:42Z

moved Clustering And Failover to appboard/old/clustering and failover

← Older revision	Revision as of 05:31, 17 July 2014
(No difference)

imported>David.moore: /* See Also */

2013-11-25T20:55:07Z

imported>David.moore: /* See Also */

2013-11-25T20:54:52Z

imported>Jason.nicholls at 12:26, 28 August 2013

2013-08-28T12:26:56Z

← Older revision		Revision as of 12:26, 28 August 2013
Line 1:		Line 1:
			{{DISPLAYTITLE:Clustering & Failover}}
	== Architecture ==		== Architecture ==

imported>Jason.nicholls: /* enPortal/Appboard Replication for Clustering */

2013-08-27T15:50:12Z

enPortal/Appboard Replication for Clustering

← Older revision		Revision as of 15:50, 27 August 2013
Line 83:		Line 83:

	#Preparation work		#Preparation work
	##In the development instance of enPortal/AppBoard, create an archive from the dev environment by running the [[~~filesexport~~\|filesexport]] command.		##In the development instance of enPortal/AppBoard, create an archive from the dev environment by running the [[Filesexport\|filesexport]] command.
	##Transfer the generated archive to the primary server's box.		##Transfer the generated archive to the primary server's box.
	#Importing the archive to the primary server.		#Importing the archive to the primary server.
Line 89:		Line 89:
	##In the primary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.		##In the primary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.
	#Synchronizing content between the primary and the secondary enPortal/AppBoard instances.		#Synchronizing content between the primary and the secondary enPortal/AppBoard instances.
	##In the primary server, create an archive by running the [[~~filesexport~~\|filesexport]] command.		##In the primary server, create an archive by running the [[Filesexport\|filesexport]] command.
	##Transfer the generated archive to the secondary server's box.		##Transfer the generated archive to the secondary server's box.
	##Validate the secondary server's database connectivity using the "portal dbsetup" command in ${TomcatHome}/bin directory.		##Validate the secondary server's database connectivity using the "portal dbsetup" command in ${TomcatHome}/bin directory.
Line 100:		Line 100:

	Notes:		Notes:
	*To verify that the above process is complete and worked correctly, you must do a full file comparison of the dev, primary, and secondary file systems to confirm that they are mirrored properly. If any custom files from the dev or primary system are missing from the secondary system, then you must modify the configuration of the filesexport command to include the additional customization files that did not get archived. For more information on this, see the [[~~filesexport~~\|filesexport]] page.		*To verify that the above process is complete and worked correctly, you must do a full file comparison of the dev, primary, and secondary file systems to confirm that they are mirrored properly. If any custom files from the dev or primary system are missing from the secondary system, then you must modify the configuration of the filesexport command to include the additional customization files that did not get archived. For more information on this, see the [[Filesexport\|filesexport]] page.
	*The database connector replication will occur automatically by the process above, because the database connection settings are stored in the file: persist.properites. Each time an enPortal/AppBoard instance is started, any load files in /server/webapps/enportal/WEB-INF/xmlroot/server/ which do not have the extension ".disabled" will be executed and the default XML content will be loaded into the database. Once the default content has been initially loaded into the database, you can remove the load files from the other instances before starting them, to prevent the XML content from being auto-loaded again into the database when that instance is started. This step would only be necessary if a server node has a new installation which is being started for the first time. The load files to remove are the following:		*The database connector replication will occur automatically by the process above, because the database connection settings are stored in the file: persist.properites. Each time an enPortal/AppBoard instance is started, any load files in /server/webapps/enportal/WEB-INF/xmlroot/server/ which do not have the extension ".disabled" will be executed and the default XML content will be loaded into the database. Once the default content has been initially loaded into the database, you can remove the load files from the other instances before starting them, to prevent the XML content from being auto-loaded again into the database when that instance is started. This step would only be necessary if a server node has a new installation which is being started for the first time. The load files to remove are the following:
	**load_reloadContent.txt		**load_reloadContent.txt
Line 109:		Line 109:
	*The default filesexport bundle includes the server.xml file, which includes some of the basic Tomcat settings (such as port number). If you have different settings for server.xml on different servers, you can allow the file to be over-written and then manually reinstate the server.xml file from a backup after executing the filesimport command.		*The default filesexport bundle includes the server.xml file, which includes some of the basic Tomcat settings (such as port number). If you have different settings for server.xml on different servers, you can allow the file to be over-written and then manually reinstate the server.xml file from a backup after executing the filesimport command.
	*The default filesexport bundle includes the persist.properties file, which manages the database connection. Procedures for managing this file may vary. Typically this file is the same across all production servers, but some care may be needed when migrating from a dev server to a prod server, which may use different databases and thus have different persist.properties settings.		*The default filesexport bundle includes the persist.properties file, which manages the database connection. Procedures for managing this file may vary. Typically this file is the same across all production servers, but some care may be needed when migrating from a dev server to a prod server, which may use different databases and thus have different persist.properties settings.


	== See Also ==		== See Also ==

imported>Mike.berman: add note for redundancy configuration setting

2013-04-01T09:36:22Z

add note for redundancy configuration setting

← Older revision		Revision as of 09:36, 1 April 2013
Line 93:		Line 93:
	##Validate the secondary server's database connectivity using the "portal dbsetup" command in ${TomcatHome}/bin directory.		##Validate the secondary server's database connectivity using the "portal dbsetup" command in ${TomcatHome}/bin directory.
	##In the secondary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.		##In the secondary server, import the archive by running the "portal filesimport" command in ${TomcatHome}/bin directory.
			#Modify the database configuration setting to support redundancy
			##Edit the file <tt>[<i>AppBoardHome</i>]\server\webapps\enportal\WEB-INF\config\hosts.properties</tt>
			##Locate the line: <tt>hosts.redundant=false</tt>
			##When running in a clustered configuration, change the setting to <tt>hosts.redundant=true</tt>


Line 113:		Line 117:

	[[Backup_and_Restore\|Backup and Restore]]		[[Backup_and_Restore\|Backup and Restore]]

			[[Database_Failover\|Database Failover]]

← Older revision		Revision as of 18:24, 17 July 2014
Line 116:		Line 116:
	CITRIX NetScaler Server Appliance		CITRIX NetScaler Server Appliance
	http://www.citrix.com/English/ps2/products/product.asp?contentID=21679&ntref=hp_nav_US		http://www.citrix.com/English/ps2/products/product.asp?contentID=21679&ntref=hp_nav_US

	~~<!-- Commented out link because it duplicates appboard/2.4/admin/backup_and_recovery and enPortal has its own backup page -->~~
	~~<!-- [[Backup_and_Restore\|Backup and Restore]] -->~~
	~~[[Database_Failover\|Database Failover]]~~

← Older revision		Revision as of 20:55, 25 November 2013
Line 118:		Line 118:
	<!-- Commented out link because it duplicates appboard/2.4/admin/backup_and_recovery and enPortal has its own backup page -->		<!-- Commented out link because it duplicates appboard/2.4/admin/backup_and_recovery and enPortal has its own backup page -->
	<!-- [[Backup_and_Restore\|Backup and Restore]] -->		<!-- [[Backup_and_Restore\|Backup and Restore]] -->

	[[Database_Failover\|Database Failover]]		[[Database_Failover\|Database Failover]]

← Older revision		Revision as of 20:54, 25 November 2013
Line 116:		Line 116:
	http://www.citrix.com/English/ps2/products/product.asp?contentID=21679&ntref=hp_nav_US		http://www.citrix.com/English/ps2/products/product.asp?contentID=21679&ntref=hp_nav_US

	[[Backup_and_Restore\|Backup and Restore]]		<!-- Commented out link because it duplicates appboard/2.4/admin/backup_and_recovery and enPortal has its own backup page -->
			<!-- [[Backup_and_Restore\|Backup and Restore]] -->

	[[Database_Failover\|Database Failover]]		[[Database_Failover\|Database Failover]]