Version Differences for Disaster Recovery

Revision as of 17 October 2012 11:20 n

Line 1:
		+	= Data Tier =
		+	== Relational Database ==
		+	Your relational database is a critical element for performance and disaster recovery. The provided Derby
		+	database, while sufficient for proof-of-concept work, is generally insufficient for the enterprise. Fullfeatured
		+	databases like Oracle, MS SQL Server, or MySQL are better options. Ideally, the database
		+	—whichever is used—should be configured for high-availability, high-performance, and be backed-up
		+	regularly.
		+	10-20 GB of database storage should be sufficient for most environments. For Oracle, an architecture
		+	based on Oracle RAC is recommended; for Microsoft SQL Server, a clustered configuration is preferred;
		+	for MySQL, utilize MySQL Cluster.
		+	== File Storage—CodeStation ==
		+	The data tier also provides log file and Codestation artifact storage. Artifacts represent deployable items
		+	such as files, images, databases, configuration materials, or anything else associated with a software
		+	project. By default, these are stored in the var subdirectory in the uDeploy server installation directory.
		+	In an enterprise environment, the default installation might not be ideal, see the section called “Relocating
		+	Codestation” for a discussion about enterprise options.
		+	uDeploy's secure and tamper-proof artifact repository ensures that deployed components are identical to
		+	those tested in preproduction environments. Without the repository, artifacts would have to be pulled from
		+	network shares or some other system, increasing both security risks and the potential for error.
		+	The artifact repository uses content addressable storage to maximize efficiency while minimizing disk
		+	use. The repository tracks file versions and maintains a complete history for all components. Maximizing
		+	efficiency is important, since the artifact repository stores files that are much larger than source files.
		+	Association of files with Components is built into the system. Without any configuration, each Component
		+	gets its own area of the repository for its files. There is no chance of confusion or mix-up of files to
		+	Components. And, each Component Package is mapped to a specific set of files and versions corresponding
		+	to the Component.
		+	The artifact repository comes with a client application that provides remote access to the repository. Using
		+	the client, the user can add/modify files, create Packages, retrieve files, as well as view the history of
		+	changes. The client application provides a file transfer capability that can be used to deliver files to target
		+	servers during deployments. This built-in transfer mechanism verifies the integrity of all transferred files
		+	against their expected cryptographic signatures, thus guaranteeing that files have not been corrupted during
		+	transmission or tampered with during storage. In addition to the client application, the artifact repository
		+	exposes REST-based web services. These services are used to build integrations between build systems
		+	such as AnthillPro and uDeploy. Such integrations automatically place the artifacts produced by the build
		+	process in the artifact repository, thus making the artifacts available for deployment.
		+	=== Relocating Codestation ===
		+	By default, the data tier's log files and Codestation artifacts are stored in the var subdirectory within the
		+	uDeploy server directory. Ideally, this data should be stored on robust network storage that is regularly
		+	synchronized with an off-site disaster recovery facility. In addition, the uDeploy server should have a fast
		+	network connection to storage (agents do not need access to the storage location). In Unix environments,
		+	you can use symbolic links from the var subdirectory to network storage. On Windows platforms there are
		+	several options for redirecting logs and artifacts, including mklink (supported in Windows 7 and later).
		+	Data Tier
		+	2
		+	If you want to relocate Codestation, relocate both the var directory as well as the \logs\store
		+	directory. A good rule-of-thumb for determining Codestation storage requirements is: average
		+	artifact size * number of versions imported per day * average number
		+	of days before cleanup
		+	Distributed teams should also take advantage of uDeploy location-specific Codestation proxies to improve
		+	performance and lower WAN usage.
		+	== Data Center Configuration ==
		+	This section provides several installation recommendations.
		+	=== Cold Standby ===
		+	uDeploy employs the cold standby HA strategy for the application tier. When the primary system fails,
		+	the cold standby is brought online and promoted to primary server. Once online, the standby reestablishes
		+	connections with all agents, performs recovery, and proceeds with any queued processes. Because the most
		+	intense work is handed-off to agents, a high performance configuration should not have an agent installed
		+	on the same hardware as the main server.
		+	The uDeploy server aggressively utilizes threading and takes advantage of any additional CPU cores
		+	assigned to it. A small to midrange server with 2-4 multi-core CPUs is ideal, but, because it is relatively
		+	easy to move an existing uDeploy server installation to a new machine, starting small and scaling as needed
		+	is a very legitimate strategy. The memory available to the application tier should also be increased from
		+	the default 256 MB to something on the order of 1 GB.
		+	=== Platform Considerations ===
		+	uDeploy agents are platform agnostic, and can be installed on anything that provides a Java 1.5 JDK.
		+	The server process is also platform agnostic. Our customer base includes large uDeploy installations on
		+	Windows, Solaris, AIX, HP-UX, other Unix flavors and various Linux platforms, all running successfully.
		+	We have seen somewhat better performance from Unix and Linux operating systems, but recommend
		+	installing on the platform with which you are most familiar and comfortable.
		+	Recommended Server Installation
		+	• Two server-class machines
		+	UrbanCode recommends two machines for the server: a primary machine and a standby for fail-over.
		+	In addition, the database should be hosted on a separate machine.
		+	• Separate machine for the database
		+	• Processor 2-4 CPUs, 2+ cores for each.
		+	• RAM 8 GB
		+	• Storage Individual requirements depend on usage, retention policies, and application types. In general,
		+	the larger number of artifacts kept in uDeploy's artifact repository (CodeStation), the more storage
		+	needed.
		+	• Network Gigabit (1000) Ethernet with low-latency to the database.
		+	Data Tier
		+	3
		+	Agent Minimum Requirements
		+	Designed to be minimally intrusive, agents require 64-256 MB of memory and 100 MB of disk space.
		+	Additional requirements are determined by the processes the agent will run. Agents should be installed on
		+	separate machines. For evaluation purposes, a good option is to install an agent on a virtual machine.
		+	=== Typical Data Center Configurations ===
		+	Most organizations configure the data tier with network storage and a clustered database. The service tier
		+	performs best when it's on a dedicated, stable, multi-core machine with a fast connection to the data tier.
		+	A standby machine should be maintained and kept ready in case the primary server goes down.
		+	=== Recovery Using a Database Back-up ===
		+	To prepare a back-up of your uDeploy installation, copy the database and server files. Back-up the server
		+	by copying the server directory along with all subdirectories. This ensures that you can revert to a server
		+	version that matches your configuration, while also preserving your artifact repository.
		+	If you are not using the Derby database, copy the database too. If you are using Derby, it was copied along
		+	with the server files.
		+	Install the back-up using the original path, or some configuration files will need to be changed.