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.
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.
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.
This section provides several installation recommendations.
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.
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.
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.
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.
