While the application management strategy in the previous section focuses on the infrastructure services that lay the foundation for applications, in this section, we provide the information about application specific processes in a production environment.
From QA to production
When an application has been fully
tested and approved to be ready for production deployment, the developer or application owner will initiate the rollout process.
An application is handed over from the quality assurance (QA) environment to production by using one (or more) templates and a set of instructions for the administrator to apply the template to an existing application or to create a new application based on this template. For more details, refer to 3.1 Using development, QA, and production servers
Since this process is most likely the same every time a new application is rolled out, you can automate this process by building a custom application that helps to manage this workflow.
Furthermore, there are application management tools for Domino available on the market that help to simplify and streamline this process.
When deploying an application from QA environment to the production system, the administrators should consider the following:
- Register each application in an application repository, which describes the purpose, ownership, location, and interfaces of this application.
Not that this is not the Database Catelog (catalog.nsf) that Domino servers maintain automatically.
- Stay in contact with application developers, work together to improve efficiency of the environment and resolve issues in a cooperative way.
- Store the templates and instructions supplied in a separate application.
This could be the application repository or another different application and is useful to review code changes that have been applied over time. Such a template repository will keep track of versions and might be shared among the developers and administrators.
- Use unique file names for applications, this will help to avoid problem in a multi-server environment where applications replicate and look up each other, for example, by referring to the file name.
- Use groups for access control list (ACL) management, and allow application owners to maintain those groups.
- Use a special signing ID file to sign design elements of the supplied template, do not use the server ID or administrator's personal ID because this might cause problems when the application is moved to other servers or if the name of the administrator changes.
Once the application is deployed to the production system, the regular production maintenance routine starts. Although the majority of work now is in control of a Domino administrator, developers are required to manage, for example, the performance impact of the growing Domino applications once they are deployed.
Access rights management
In an efficient Domino environment, access rights management does not require administrators to perform any changes because application owners are able to grant and deny access to users by modifying groups in the Domino Directory. You should document the process for the users to find this information easily, for example, by establishing a wiki that explains how owners can manage access rights by themselves.
Consider these good practices for access rights management:
- Manager and designer access are exclusive to administrators and servers.
No user and no developer should have access rights higher than Editor in a production environment. Changes in existing applications should be performed by the Domino administrator by handing over design templates to the Domino administrator. This process should be agreed and documented within your organization.
- Run scheduled agents that require restricted or unrestricted functions using "On behalf of" with an application ID,
This ID does not need to be a real Notes ID, it is just a name that you will use to grant access to resources that the agent has to access. This method allows you to grant and deny access in a more granular way.
Availability of an application includes more than the ability to open the application as such. The application must function as defined in the requirements and must work as expected by users. The term availability is often misunderstood as end-to-end availability, anywhere, anytime. This type of availability is often beyond the management ability of the administrators and developers because they only have a subset of the environment in control. For an end-to-end availability, other components such as local and wide area network, user device, and so on are of importance. Therefore, if end-to-end availability is a requirements, the application should be designed to meet this criteria by including a broader vision on infrastructure.
In order to improve availability of a Domino application, the following items should be evaluated:
- Utilize Domino clustering to provide high availability.
This requires an application to be built for clustering, which means developers have to avoid using, for example, references to individual server names or using unique numbering systems that are computed on one server only.
- Decentralizing Domino application servers.
While consolidation and centralization is good for mail servers, Domino applications work very well in a decentralized environment. Local application servers can provide users who are in the locations with poor network connections the performance and application availability they require.
- Separating applications with low performance needs from those with high performance needs.
This is where the classification of applications becomes important. With this classification, the administrators can host a large number of small applications on one server, while a different server is hosting a low number of applications with high performance needs.
Once an application is established in an environment, it should be monitored. You should separate the infrastructure monitoring from the application monitoring. For infrastructure monitoring, refer to the IBM Redbooks publication Optimizing Domino Administration
, Chapter 3.1:
While in some environments, it is acceptable to monitor the infrastructure and Domino server layer only, the complex environments with business critical applications might have certain applications that require more attention. However, due to the large variety of Domino applications and its functionality, it is not possible to predefine what should be monitored within an application. This list will give a short overview if what can be monitored:
- Usage tendency: For example, number of read and write activities, FTIndex usage,
- Growth statistics: For example, number of documents in the database, number of custom views and folders, size of documents and the attachments within
- Efficiency: For example, Agent runtime, time to render a specific page number.
You can monitor these triggers from within the application itself by custom developed monitoring agents that alert the application operators in case of any abnormal or can be part of an existing application monitoring system for example, Domino Domain Monitoring (DDM) or Tivoli ITCAM for applications
Virus scanning is important in every environment regardless of its size, however, individual settings and practices might cause drawbacks on system health or performance.
A common approach is to enable virus scanning on both the server and the workstation, while each of them focus on different items. Serious performance issues can occur if virus scanners on operating system level are configured wrong. Since Notes and Domino are accessing and modifying a large number of files on the disks at the same time, local virus scanners will interrupt read and write access at every time. Therefore, the disk I/O throughput for the server and the client will reduce dramatically resulting in a performance issue.
Here are a few examples to outline which anti virus settings should be used:
- Operating system virus scanner shall be configured to skip any Notes or Domino data.
- Application specific virus scanners shall be used to scan Domino data,
- Scanning applications on access will ensure that a document or attachment that is being opened by a user does not contain any virus.
- Virus scanners shall not modify documents stored in applications, although it might sound like reasonable for cleaning a virus. This will cause replication conflict problems when an application is distributed to multiple servers.
Backup and recovery
A Lotus Domino server backup can not be handled like a file server because Domino is keeping a large number of files opened and is performing background actions against those open files even if there is no user accessing them. Relying on normal backup software that is not aware of how to handle open files can be dangerous, as this software might claim a file as locked when Domino is trying to access. This will cause the “This database is currently being used by someone else...” error in Domino.
For more information about Domino server backup and recovery, refer to http://www-10.lotus.com/ldd/dominowiki.nsf/dx/3.9_Backup_a_Domino_Environment
Remember the following
- Define and understand the backup policy of your corporation. Certain data might be required legally to be kept for longer than other data, so an individual backup plan for an application might be required while other applications can use the default server backup routine.
- Include the Domino Attachment and Object Services (DAOS) repository in your backup and recovery plan.
- Perform regular tests against the backup infrastructure to make sure you can restore the data that was backed up.
For example, perform a full restore to an empty server once per year.
- Define your application restore scenario in written form, and make sure the administrators have an appropriate understanding of specific actions that must or must not be performed. for example, some applications contain scheduled agents that run by schedule to send mails. When restoring an application to a different server, you might not want those mails to be sent. Therefore, define what needs to be done to avoid this.
For additional information on how to efficiently restore an application, refer to http://www-10.lotus.com/ldd/dominowiki.nsf/dx/3.10_Restore
Parent topic: 2.0 Application development lifecycle