WO2008124181A1 - Système et procédé d'édition de centre de traitement de données - Google Patents

Système et procédé d'édition de centre de traitement de données Download PDF

Info

Publication number
WO2008124181A1
WO2008124181A1 PCT/US2008/004635 US2008004635W WO2008124181A1 WO 2008124181 A1 WO2008124181 A1 WO 2008124181A1 US 2008004635 W US2008004635 W US 2008004635W WO 2008124181 A1 WO2008124181 A1 WO 2008124181A1
Authority
WO
WIPO (PCT)
Prior art keywords
instance
application
upgrade
template
software application
Prior art date
Application number
PCT/US2008/004635
Other languages
English (en)
Inventor
Jacob Taylor
John Roberts
Clinton Oram
Lila Tretikov
Joseph Parsons
Original Assignee
Sugarcrm Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sugarcrm Inc. filed Critical Sugarcrm Inc.
Priority to EP08742728A priority Critical patent/EP2145254A4/fr
Publication of WO2008124181A1 publication Critical patent/WO2008124181A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • Appendix A is a spreadsheet showing the seed data for an Account table of the SugarSuite system. Appendix A forms part of this specification.
  • a software-based system is described and in particular a system and method for deploying a software-based system using one or more hardware components are described.
  • the deployment of a single user/single enterprise software-based system is relatively straight-forward in that the software is installed on a computer and executed on that computer.
  • the deployment of a software-based system across a wide geographic area is more difficult since it is not possible to have a single installation of the software due to network latency and other issues.
  • An application clustering system and method are provided wherein the system may include a set of geographically distributed nodes (where each node is typically composed of a cluster of servers). In addition, each customer instance is served by a primary node, with hot stand-by nodes in different locations.
  • the system may also have data centers in US East, US West, and Europe each hosting multiple nodes for capacity growth and fault isolation.
  • the system may also include storage area network and network storage appliance units in each node for high performance and storage reliability.
  • Figure 1 illustrates an application clustering system
  • Figure 2 illustrates more details of the server cluster of the application clustering system shown in Figure 1 ;
  • Figures 3 A and 3B illustrate a high level diagram of the network layer of the server cluster of the application clustering system
  • FIG. 4 illustrates deployment of an application in a data center edition (DCE) environment system
  • Figure 5 illustrates a partial database schema for a table of an application in the DCE system
  • Figure 6 illustrates a template sandbox upgrade method of the DCE system
  • Figure 7 illustrates a template quick upgrade method of the DCE system
  • Figure 8 illustrates a source and sandbox environment of the DCE system
  • Figure 9 illustrates a centralized scheduler for the DCE system. Detailed Description of One or More Embodiments
  • the system is particularly applicable to a customer relationship management software application system (a SugarCRM system) and it is in this context that the system will be described. It will be appreciated, however, that the clustering system and method in accordance with the invention has greater utility since the clustering system may be used with a variety of software applications wherein those software applications benefit from the clustering system and method.
  • a Customer relationship management software application system a SugarCRM system
  • An example of an exemplary embodiment of the application clustering system may be the Sugar On-Demand system which is a product offering from SugarCRM Inc.
  • the Sugar On-Demand system is a scalable grid of computers around the globe working together to provide a seamless user experience for millions of end-users.
  • Each node in the grid is itself an independent installation of Sugar On-Demand.
  • These nodes when coordinated, can provide disaster recovery for each other.
  • the system uses well known, typical components as much as possible to avoid specialist knowledge, avoid the cutting edge, and keep predictability and reliability high.
  • FIG. 1 illustrates an application clustering system 20.
  • the system 20 may have one or more data centers 22 (such as a US East data center 22 1 , a US West data center 22 2 and a Europe data center 22n in the example shown) that may be geographically distributed and coupled to each other over communications links, such as a computer networks, communications networks, cellular networks, WiFi networks, etc. so that the data centers can exchange data and information with each other.
  • Each data center may host one or more nodes 24.
  • the capability to support one or more nodes in a data center provides for easy capacity growth and fault isolation. Multiple data centers should be geographically distributed to provide instances located near the end users (to provide more efficient transmission of data) and provide further fault isolation.
  • Each node 24 may further comprise a cluster of servers 26.
  • Each customer instance 28, such as customer instance 28 1 and 28n shown, is served by a primary node, with hot stand-by nodes in different locations (for fault isolation) available as needed.
  • Each customer instance in the embodiment, is an installation of the SugarCRM customer relationship management software application that is used by the people associated with the customer instance.
  • the system 20 may further comprise well known storage area network and network storage appliance units in each node for high performance and storage reliability.
  • the system 20 shown provides fault isolation because, if a primary node of a - - customer instance in a particular data center fails (maybe due to a problem with the data center or its connectivity), the backup node or nodes for the particular customer instance is located in a different data center in a different location so that it is more likely that the backup node will be able to take over when the primary node fails.
  • FIG. 2 illustrates more details of the server cluster 26 of the application clustering system shown in Figure 1.
  • Each cluster of servers 26 may include four layers including a Networking layer 26 1 , a Web Server layer 26 2 , a Database layer 26 3 , and a File System layer 26 4 .
  • Each layer may be implemented by a computing device, such as a server computer or any other processing unit based device, that has the typical server computer components and executes one or more software applications as described below.
  • the Networking layer consists of the firewalls, switches, and load balancers as shown in Figures 3 A and 3B.
  • the Web layer consists of the web servers running the software applications, such as applications like SugarCRM in one example.
  • the Database layer consists of database servers that store the applications and the data and information associated with the applications.
  • the File System layer consists of a managed file system. It is preferred if the file system in the File System layer is cluster aware and automatically replicates itself among the appropriate nodes.
  • FIGs 3 A and 3B illustrate a high level diagram of the network layer 26 1 of the server cluster 26 of the application clustering system.
  • the networking layer is primarily responsible for making sure that the correct level of access is provided, providing appropriate connectivity between the machines, balancing load among the servers, and assisting in failover.
  • An example of the architecture of the networking layer is shown in Figures 3 A and 3B.
  • Each server in a cluster (a machine) should have redundant network connections to redundant switches and all of the machines should be connected by at least a 1 gigabit network.
  • firewalls and network monitoring devices may be used to protect the network from intrusion. For normal operation, only https and http traffic needs to be allowed, SSH is also desirable for system management but is not required.
  • Each load balancer serves three primary purposes. Each of these purposes is implemented by one or more lines of computer code that are executed by a processing unit in the load balancer unit that implement the purposes described below. First, it serves its traditional function, sharing load among the multiple machines in a single layer. For many systems, it is desirable to have session affinity turned on. PHP (a known scripting language used to create dynamic web pages) session IDs are passed in cookies (or the URL if cookies are disabled) and should be available on every request.
  • PHP a known scripting language used to create dynamic web pages
  • a shared file system in which the sessions are stored, would make affinity redundant. Having cluster aware software that coordinates the sessions and makes them available to the entire layer would also render affinity redundant. Having most requests from one session go to one web server allows for better use of cache. Each round trip for dynamic content needs the session information in order to complete. If the session information is already cached on the server, then it does not have to be retrieved from the shared storage.
  • the second main purpose of the load balancer is to provide automatic failover to an alternate system should one of the primary systems fail. This can be failover between network cards, switches, or an entire server or node that is no longer functioning or is overloaded.
  • monitored system load metrics would also be used as criteria for switching between machines.
  • the final main purpose of the load balancer is to encrypt and decrypt SSL communications. Leveraging SSL provides enhanced security for critical data. Using the load balancer to encrypt/decrypt the traffic is a good way to make sure the enhanced security does not come at the cost of too much server load.
  • the database layer needs the ability to communicate among the servers internally, reach the file system, and be reachable from the web server layer on specified ports.
  • the load balancing of the databases is a little trickier than load balancing the web servers.
  • the databases must be checked for consistency and most likely, the old master will be configured to be the backup master.
  • the web server layer needs to be reachable from the outside and needs to be able to reach the database layer.
  • Servers in the web server layer need to be able to communicate with each other if there is cluster aware software running on the systems. If they are only leveraging a common file system, they do not need access to each other.
  • the database layer needs to be reachable from the web server layer.
  • Proxy Server Layer This system is designed to operate over huge geographic distances and networks may not provide sufficient bandwidth for a satisfactory user experience.
  • local web proxy servers may be used to provide several key benefits. Among the potential benefits are:
  • Web proxies In general, while the use of web proxies is not required they are a great way to boost end user performance. They can be deployed at any level, from regionally around the world all the way down to actually at the customer's location.
  • Web Server Layer The web layer is typically composed of a grid of simple off the shelf systems running identical platform software with the application, such as SugarCRM in the preferred example, running on the systems. They must have a common application image in order for them to effectively form a SugarCRM cluster to function correctly. Processor and network throughput are the primary things to purchase for on this layer.
  • the web layer should leverage PHP accelerators.
  • PHP accelerators save a lot of processing on the server side with every round trip.
  • PHP re-parses all files on each round trip from scratch (only the operating system file cache provides any speedup).
  • AU PHP accelerators save intermediate states of page compilation and many have no PHP compilation after the first run, just execution processing.
  • the Zend Platform for instance, has the ability to cache PHP in different states of processing, greatly decreasing the work on each round trip. It also has the ability to manage sessions across the cluster (keeping them in memory and only writing them to the file system for failure recovery). It also has the ability to efficiently transfer large files through PHP and cache generated output across sessions.
  • Three other accelerators are APC, php-accelerator, and eAccelerator.
  • the Zend Platform has been known to work well with Sugar under heavy load; the other accelerators are under testing.
  • the database layer will differ significantly depending on the database that you are using. From the application perspective, there needs to be at least one server IP Address and credentials that the application can use to read and write data. As the application evolves, it will have increasing ability to leverage read-only slaves from a cluster in order to remove hotspots from the cluster. The majority of a CRM application's queries are read only. Eventually, reporting database servers will be supported. These three layers of database servers can be collapsed transparently if the read-only servers or reporting servers fail or become unavailable.
  • Persistent database connections should be enabled. This will save time spent connecting to the database on each round trip.
  • Sugar uses a single database connection for all queries in one round trip. The connection is made at the beginning of the page processing and is released at the very end. Protect the network between the web servers and the database server. This allows for the communication between web server and database to be unencrypted. This will also save processing power.
  • the currently supported databases may include MySQL and Oracle.
  • All writes should go to a master.
  • the system may be setup so that if the primary master were to fail, all of the slaves would replicate off of the backup master and all inbound queries would go to the backup master as well.
  • the cluster can be reconfigured to re-label the primary and backup masters or the primary master can be recovered.
  • the publicly available MyISAM is an excellent storage engine that performed well during testing and MyISAM is very fast and flexible.
  • the publicly available InnoDB should be considered.
  • the master would leverage InnoDB and the slaves would leverage MyISAM.
  • This configuration provides the enhanced locking and transaction capabilities of InnoDB while still allowing the speed, flexibility, and full-text search capabilities of the MyISAM engine.
  • an administrator set the default engine and code page to the values that the administrator wants the application, such as SugarCRM, to use.
  • Oracle is a well-known database to the enterprise market and most enterprise companies have Oracle database administrators (DBAs) already on staff. For this reason, the example application (“Sugar”) supports both Oracle 9i and 1Og databases.
  • Sugar is configured to create all tables and indexes in the default tablespace of the user. It is recommended, however, that indexes are created in a different tablespace in order to reduce contention. At this time, the easiest way to accomplish this is to get a dump of all indexes, drop them, and then recreate them in another tablespace. In the future, the Sugar application will be ask for appropriate tablespace names during the installation process.
  • File System Layer A Sugar Suite that may be an installation of a suite of software applications that includes the SugarCRM customer relationship management application described above, is composed of many files.
  • the files fall into one of several general categories. Each of the categories is detailed below along with approximate sizing.
  • Application files are the primary files that compose the Sugar Suite.
  • a clean install of 4.2 Professional or Enterprise are composed of roughly 6,000 files which take roughly 40 MB of disk space. These initial files are infrequently modified, but are frequently read. All application functionality is coded in these files.
  • Application Customizations are the primary files that compose the Sugar Suite.
  • a clean install of 4.2 Professional or Enterprise are composed of roughly 6,000 files which take roughly 40 MB of disk space. These initial files are infrequently modified, but are frequently read. All application functionality is coded in these files.
  • Application Customizations include new modules, new logic, override files, language packs, and any other enhancements made to the Sugar Suite at the file system level. These modifications would generally not be expected to be more than the same rough size as the initial application files. It is quite possible, however, that the customizations will be far larger than the base application.
  • Attachments are one of the quickest growing segments of files in the application.
  • the use of uploaded files is dependant on the use of the Sugar Suite by each enterprise. Some enterprises quickly end up with gigabytes of attachments; others only have megabytes of attachments after a long period of time. If the particular enterprise practices attaching files to opportunities, accounts, cases, bugs, etc., then it is highly recommend that the enterprise sets aside a good deal of storage space to accommodate the size of the attachments based on the business process. For example, SugarCRM Inc. (that distributes the Sugar Suite) recommends that at least 20 GB be ear-marked for this purpose at the time of installation and expand as needed over time. This approach will provide enough storage for most implementations in the beginning while providing visibility into actual usage allowing the enterprise to adjust and manage the filesystem appropriately.
  • attachments An attribute of attachments is that they rarely change. Once a file is uploaded the application leaves it intact. As a Best Practice recommendation, it's a good idea to perform maintenance from time to time to clean out old files. Coincidentally, users expect a reasonable delay when retrieving an attachment. As such, attachments can be stored on slower disks in the SAN or on the inner part of the disks. For this reason, less expensive drive arrays can be used for the larger attachment folders since they will be less frequently accessed and users should have a higher tolerance for small delays (there is only one attachment per round trip as compared to possibly over one hundred read files for a normal page).
  • Cache files are generated by the application during normal processing.
  • the graph data is calculated and stored in an XML file.
  • the XML file is re-read instead of being recalculated. It is important that cache files for a particular session be available on the next round trip. This can be accomplished via a shared filesystem or session affinity with periodic file synchronization.
  • Log files during development, testing, and tuning can be quite large.
  • the log level is typically set to FATAL which drastically decreases the growth of log files.
  • Log files are typically stored in the root of the application folder.
  • the log files are rather frequently updated. It is important that this not become a source of contention for a shared file system. To this end, each web server should have a local log that it writes to that is then later merged with the other logs (or copied to a common location).
  • Configuration files rarely change. There are a few reasons why a user might want to have different configuration files for each of the web severs in a cluster, hi general, all of the webserver(s) should be configured in the same manner.
  • Session Files hi a cluster of web servers it is best if a cluster session manager is used in which case a shared file system can be used to store a copy of the session data in case of system failure. If a cluster session manager is not used, the user can store all of the sessions in a shared files system.
  • the session files are read and written on each round trip to the database. In addition, the data from the last round trip may be present when processing the next round trip (i.e. the cluster file system must operate as a single global file system for session files).
  • the application clustering system may also provide redundancy to each cluster including network redundancy, power redundancy, database redundancy, server capacity, file system capacity, monitoring redundancy, multi-site redundancy, backups and adverse condition strategies.
  • the adverse condition strategies may include a notification plan for virus attack, massive hardware failure, local catastrophe, DDOS Attack, hack attempts, successful hacks, security vulnerability, customer load tests, poor customer customizations, operational maintenance and urgent unplanned maintenance.
  • the redundancy provided by the system also may include regular maintenance.
  • the system may also provide capacity planning which may include capacity planning for the file system, for the network, for power, for space and for backup.
  • capacity planning may include slow files (files such as uploaded content and cache folders.) They do not change often and can take a little while to retrieve (much longer than one of the PHP pages used in common UI responses), application files, application customizations, uploaded files, logs, configuration files and database files.
  • the network capacity planning may include end-user, backup, sync and monitoring.
  • the system may also provide rapid growth capacity planning.
  • the system may also provide access control that may include ION, customer databases, customer files and/or shell accounts.
  • the system also may provide monitoring that may include simple repair actions that need to become automated, every round trip being logged, the file system, the database, the processing units (CPUs), system loads, memory, swap and ideally queries and stuff based on sampling.
  • the system may also provide rollout testing that may include how new versions or new scripts, etc are rolled out or the process to follow before pushing the update button.
  • the system may also provide production, load testing, quality assurance (QA), a customer sandbox environment, security and a shared file system.
  • the customer sandbox environment may give Customers and professional services (PS) people access to a sandbox to edit their application and give them the ability to reset their instance, or migrate changes into production.
  • PS professional services
  • Each of the data centers 22 shown in Figure 1 may include a data center edition application (DCE) system that encapsulates management, monitoring and deployment capabilities for, in one embodiment, a SugarSuite installation where the SugarSuite installation is a suite of software applications that includes the SugarCRM customer relationship management application described above.
  • DCE data center edition application
  • Each of the capabilities of the data center edition application (DCE) may be implemented, in one embodiment, as one or more lines of computer code that are executed by a processing unit of the computing device that executes the DCE application.
  • SugarSuite may be composed of: • Configuration Files - These files are used to extend, configure, and point the
  • SugarSuite installation to resources it has available may contain folder locations, template information, instance settings, and connection information for the database, file system, cache, ...
  • Uploaded Files These are files that have been uploaded to the instance and potentially linked to records in the system. These files may include, but are not limited to: contracts, documents, images, logs, ...
  • Cache Files These files are dynamically generated by the system and used to decrease the cost of repeated calculations. Template rendering frequently leverages caching to improve performance.
  • Another good example of a cache file is a composition of metadata for sub-panels. For a detail view like the account detail view, there may be a collection of sub-panels under the detail view. Each module that would like to make a sub-panel available on the account detail view provides metadata. The system calculates the metadata for the entire view (based on the contributed metadata) and caches the output metadata in a cache file.
  • Phantom file caching non-existent file references may be cached to avoid spending resources on the unnecessary operations.
  • Application Files These files are the basic application. All of the application logic is contained in application files. In the case of SugarSuite, the application files are typically .PHP files.
  • logs are critical for keeping track of system performance, tracking issues, and monitoring the system for errors or intrusion attempts.
  • Session Files contain information about the user that is interacting with the system. Sessions may be stored in memory, on a dedicated server, in the database, or on disk. If the sessions are stored on disk, the session files will need to be stored where they are isolated from other instances of SugarSuite and available to PHP.
  • Temp Files During the processing of the application, the system may need to create temporary files from time to time. These files are typically stored in a temporary folder to keep them isolated from the rest of the system.
  • Another aspect of the DCE system may be the ability to provide an intelligent cache designed to decrease the file system or processing load produced on or by the web servers.
  • caching file accesses will decrease server load.
  • One common issue in a system composed of components that reside in multiple folders where an included file can be located in one of many folders is determining which folder a file should be included from. Ln an instance of sugar in DCE, it is important that the system be able to quickly figure out which path a file comes from. To that end, a cache of the result of determining where a file is located, either by folder or by individual file, may be kept to help reduce redundant searches through the file system.
  • Another common extension point in Sugar is the automatic inclusion of extension files if they are present.
  • the implementation of this requires the system to frequently check to determine if a given file is present or not. If the file is present, this file is cached by the operating system. If the file is not present, this file is typically not cached by the operating system. This leads directly to disk load.
  • the system may cache files that do not exist just like it caches the files that do exist. This cache would offload the file system and prevent it from performing complicated searches for files that, in the end, do not exist. The fact that the files do not exist may be stored by directories or filename.
  • the DCE system allows users to function as administrators of distributed installations of the Sugar application and view system and application related reports from within a unified application management console.
  • the DCE system may be comprised of several high-level features that include deployment composition, deployment management and license management, monitoring, alerts and reports and access control management. All of these features are subject to access control as well as general Search & Filter capabilities because this system must comply with all guidelines (including UI, design, administration, coding practices and frameworks) set forth by SugarSuite documentation available at www.sugarcrm.com which are incorporated herein by reference.
  • the DCE system can manage, monitor and deploy applications on the following platforms: Linux platforms (including the commercially available UBUNTU 6.1.0 and/or Red Hat Enterprise Linux (RHEL) 4.0), Windows Platforms (including XP, Vista, Longhorn and/or Windows 2000), databases (including MySQL 5.x, Oracle 1Og and/or SQL server) and/or web servers (including Apache and/or US).
  • Linux platforms including the commercially available UBUNTU 6.1.0 and/or Red Hat Enterprise Linux (RHEL) 4.0
  • Windows Platforms including XP, Vista, Longhorn and/or Windows 2000
  • databases including MySQL 5.x, Oracle 1Og and/or SQL server
  • web servers including Apache and/or US.
  • a deployment is a single instance of SugarSuite deployed in the DCE environment as shown in Figure 4.
  • a deployment may include the following properties: zero or more virtual host folders with all code and files specific to an instance of SugarSuite; zero or more links to the template folder to use with an instance (generic files for specific version of SugarSuite); and/or a database schema instance (could be seeded with data or empty); or a link to an existing database (DB) instance that can be a shared database.
  • the environment of the deployment as shown in Figure 4, may include a DCE template that is used for one or more instances of the application, such as Instance A and Instance B as shown in Figure 4 wherein each instance may be based on a database schema instance, such as schema A and schema B as shown in Figure 4.
  • Each instance is associated with a template so the templates->instance relationship is one-to-many.
  • Each template is either 1) an unmodified release and/or patch versions of a SugarSuite; or 2) customized releases specific for groups of users and possessing a specific and well-defined combination of features (such as for instance a Real Estate Template).
  • the templates function as a generic code-base for a number of further customized instances.
  • the instance customizations work by overriding the template version of a file via introducing a customer version in a sub-location.
  • the SugarSuite software uses the customized file version if such version is available, or the generic "template" version otherwise.
  • Each template instance may have one or more of the following properties:
  • the instances of SugarSuite are distinct instances of the SugarCRM application at distinct URLs generally created for a variety of purposes. Each instance must be based on one SugarSuite Template. A typical use of instances can include creating development, stage and production versions of an application. Each instance may have one or more of the following properties:
  • Each Instance will send heartbeats to the heartbeat server. • Each Instance will be associated with a Template and orphan instances are not allowed.
  • Each SugarSuite Instance must be linked to a database schema as shown in Figure 4.
  • Each new installation of a SugarSuite instance must install a corresponding DB schema as well as to configure the Instance for DB access.
  • the SugarSuite DB Schema may have the following properties:
  • Figure 5 is a partial view of an account schema that is part of the SugarSuite DB Schema.
  • the account table is at the center and many of the related tables and relationship tables are present.
  • the accounts and contacts tables may be related with a relationship table (Accounts/Contacts) in the middle is a typical example.
  • Appendix A contains a spreadsheet with the seed data for the account table shown in Figure 5.
  • An example of a sample SQL statement for creating the Accounts table for SugarSuite on a MySQL database is as follows:
  • billing_address_city " varchar(IOO) default NULL
  • ticker_symbol' varchar(10) default NULL
  • DCE may include the capability to automate detection, download and execution of software upgrades based on the information provided by a remote server as well as local installation/modification metadata created by the DCE on the target system in response to user actions.
  • a remote server mentioned above may be a server that the system knows to go to in order to look for and/or download updates. Once connected to the remote server, in addition to looking to see if new updates are available, the system may download the new updates directly from the server.
  • These upgrades can be executed either manually or automatically by the system. To enable this the upgrade files must contain template components and instance components.
  • the template components may include files to copy or replace on the target system and/or any scripts necessary to execute the file upgrade.
  • the instance components may include files to copy or replace on the target system, any scripts necessary to execute the file upgrade, a database schema to copy or replace on the target system, and/or any scripts necessary to execute the database upgrade.
  • Deployment Management allows SugarSuite administrators to create, delete, deactivate and otherwise manage distributed SugarSuite installations.
  • Deployment Management spans Template management, Instance Management, License Management and Access management, each of which is described in more detail below.
  • Each Instance is associated with a Template; in other words Templates->Instance relationship is one-to-many.
  • Templates allow DCE administrators to logically and functionally organize their installations of SugarSuite. Multiple Sugar instances extending a single Template will share all specific functionality of that template amongst them. However, they can further individually enhance those customizations. This kind of organizational model for shared- tendency installations will allow for simpler methods of managing, installing and removing new instances of the software.
  • all the deployment management functions are subject to Access Control rules.
  • the template management may include one or more of the following functions:
  • Copy and clone template (primarily for customization). This process may be done when the user wants to create multiple instances that share substantial customizations.
  • Upgrade a Template Template upgrade can be fully automated, partially automated or a fully manual process.
  • Two main kinds of upgrades will be readily available: a Sandbox Upgrade (see the exemplary method shown in Figure 6), which will create a complete replica of all relevant files in the current installation, execute and validate the upgrade, run automated sanity checks and make the new environment available for user acceptance testing and a Quick Upgrade (see the exemplary method shown in Figure 7), which will execute validation and consequent upgrades directly on the live installation.
  • Some of the different upgrade options may include:
  • o DCE configuration to automatically download new updates for any version of Sugar that is DCE-ready to be applied to any templates.
  • o DCE configuration to automatically apply security patches to templates based on the patched product.
  • o DCE configuration to automatically apply general patches to templates based on the patched product.
  • o DCE configuration to automatically apply new versions and upgrades to get to new versions.
  • o DCE configuration to automatically extend upgrades to associated child instances.
  • Temporalating feature may be implemented in various ways to conform to specifics of the environment including, but not limited to: languages, interpreters, and platforms. Regardless of the specific implementation, effective caching may be an important contributor to performance. Sharing common files and loading directly from a common template will decrease the number of files loaded and parsed and will boost cache effectiveness. A few proposed methods for implementing the templating feature are the follows:
  • Utility Functions which provide a centralized way to retrieve the full path of the source file that should be used when a file inclusion is attempted.
  • this utility is called SugarTemplateUtils.
  • a single tier of templates is supported, but multiple tiers of templates may also be supported.
  • An example of a multiple tiers of templates would be an environment where there may have a base template as shipped from Sugar. There may then be a template created based on that template that provides extra functionality and/or changes the system to be targeted to a specific audience like a real estate vertical. Specific instances may be created based on any level of the template. A user may create an instance based on the original code, or the real estate vertical. When updates are applied, the user can roll the updates down through the layers of templates. This extra capability of templating may help the user maintain customizations from which multiple templates are derived.
  • Instance Management A SugarSuite Administrator must be able to manage a range of SugarSuite instances, modify/customize those instances, and perform other management duties as listed below. Zero or more SugarSuite instances might be linked to a Template, but each instance is associated with only one template. As with the other deployment management functions, the Instance Management functions are subject to Access Control rules.
  • FIG. 8 shows the source environment and the sandbox environment wherein there are two instances (Instance A and Instance B) based on the DCE template for the source environment and there are two clone instances (Instance A Clone and Instance B Clone) for the DCE template Clone for the sandbox environment.
  • This logical type of instance can be highly restricted or can allow full access.
  • Delete Instance Allow for "expiration timer” to automatically remove instances if "auto-expire date” has been set. This is useful for demo or sandbox instances. o Remove all associated services (a.k.a. mail, CVS). o Deactivate Instance (i.e. make inaccessible to users, but do not delete files, services or DB schema)
  • the user can choose to NOT copy attachment files. o
  • the user can select another DB vendor (note schema must be interchangeable and the cloning process must adapt configurations accordingly) o Allow the user to select application server. o Allow the user to set "auto-expire" timer for this instance. o Allow the user to select another template. o An optional copy of the DB schema will be created. Creation options are as follows: ⁇ The user can copy all data from donor schema. The application should display the size and estimated time to copy.
  • the user can create an empty copy of the donor schema (no data present).
  • the user can create an empty copy of the donor schema and populate this with seed data.
  • the user can create a copy of the donor schema with some data removed or mangled.
  • the user can skip schema creation and allow the clone instance to use donor schema.
  • Instance Editing Allow users to check-out & edit instance files. o Track all changes to DB Schema, File, and UI. o Allow user to Undo/Redo changes. o Seed Data (useful for Demo Instances) o Associate/Re-associate Instance to a Template, o Back-up/check-in/merge files. 5. Upgrade to Template
  • Exports may contain some or all of the changes made to a system. Changes may be selected based on type of change and/or modules affected. Examples of types of change that may be exported include: 1. Custom Fields (all, additions, removes, modifications)
  • Metadata files (user interface, data model, logic control, %)
  • Exports may be compressed using a common compression technique such as Tar-Gzip or Zip.
  • ⁇ Exports may be complete or based on a particular state of the system. For instance, if the user has made a lot of customizations and then create a sandbox, the user can export all changes, or changes made since that sandbox was created. This allows quick and easy additional changes to be exported from a heavily customized instance. o Import Customizations
  • Imports support bringing in changes from exports done on other systems.
  • the user may be able to choose which type if changes to import and/or filter the import based on module. For example, you may want to pull in only the UI layout changes that were made to the contacts module.
  • the import process may perform a merge of the changes. If there are conflicts, there may be an automatic mode where one of the two sets wins (either the set being imported, or the existing set). There may also be a manual mode that allows a human to decide which change wins in the event of a conflict.
  • ⁇ There may also be a mechanism to show some of the changes and/or conflicts in the User Interface to allow the user to see what the conflict is and potentially merge specific portions of the changes into a final result.
  • One example would be to show three views of a customized user interface: the two conflicting views and the target. From this view, a user is able to select which result the user likes better from the other two views and potentially make additional changes directly in the target view.
  • the system will apply the necessary file changes, file manipulations, database schema changes and data manipulations to make the instance compatible with the new template.
  • a cluster consists of a number of "virtually headless” web servers (these might include
  • Each web server must be configured with a set of rules to discover the SugarSuite Instance referred to by the request URL.
  • Each SugarSuite instance may include the following configuration files for access to the DB cluster: • Set permissions of SugarSuite Instance files.
  • Figure 9 illustrates a cluster of servers 26 that includes the DCE servers that are connected to one or more centralized schedulers which abstracts all asynchronous jobs of each individual instance into a centrally executed task.
  • the goal of this feature is to alleviate and to control the load generated by individual servers and to enable single point of control for the system administrator.
  • Centralized scheduling allows for the control of resource usage devoted to scheduled tasks.
  • Centralized scheduling allows limited resources to be spread among the highest priority tasks.
  • the centralized scheduler may have a table that stores the instances, the scheduled jobs for the instances, when they were last run, and/or when they are next due to be run. The centralized scheduler may then leverage this information to distribute work to a single machine that is processing the scheduled items, a cluster of machines dedicated to processing scheduled items or to the web servers in the cluster running the application.
  • DCE may provide a User Interface to manage dynamic application functions.
  • the system may allow for the following runtime tasks:
  • the system may implement a mechanism for tracking and reporting on system-wide dimensions, application coordinates (delivered via heartbeats), and change logs. Examples may include
  • the DCE may also support product change.
  • the product change functions may include one or more of the following:
  • the DCE may provide monitoring, reporting and alerts that may more specifically include monitoring and backups (system and instance monitoring), backups, reporting, dashboards and alarms. Monitoring & Backups
  • System Monitoring may provide information on all components in the cluster (Servers, Routers,).
  • Application monitoring will provide data specific to every individual instance of Sugar's performance across the DCE cluster.
  • the cross-section of server-application performance may provide valuable insight into the overall performance of the cluster and allow for further tuning of servers and instances.
  • System Monitoring Administrator should be able to monitor system performance, application performance across Instances and Application Performance on per-instance basis.
  • the system monitoring allows administrators to monitor performance of the system running SugarSuite Instances and the following system parameters will be available: Server names or IPs being monitored and statistics (current) for each Server: CPU, Memory, disk utilization (throughput levels and space percentage), Number of Concurrent Live Sessions, any currently blocked requests (Locked Queries, connections waiting on a server, connection pool limits reached, ...) and/or component specific response times that may include server response times, database response times and routing delay.
  • the monitoring may also allow the Administrator to monitor the current instances of Sugar in the DCE ecosystem.
  • An instance of the application can be deployed on numerous physical servers and multiple logical servers (clusters).
  • the monitoring information needs to be forwarded to DCE to provide a reconciled view of the information provided by the System Monitoring component to create a coherent picture of the DCE ecosystem.
  • the data on the performance of each instance will then be available.
  • the following performance information may be available to the DCE Administrator:
  • UI UI
  • the information should also be filterable by date/time, instance, module, action, and response time. These filters should be able to be used in any combination.
  • This level of filtering presents a unique way to view the performance of the server.
  • the user can start at a high level UI that shows there is some degradation of performance.
  • the user can then drill in and see that the issue appears to being caused by one instance on a cluster.
  • the user can then drill into that instance and see that one module is causing most of the slowdown and it appears related to list views on that module.
  • the user can look at individual page tracking to see if all list views are a problem or just ones that are filtered in a particular way. This drilling down process on the logs gives the user a very powerful view into the system and will highlight any problems or places that the user can tune.
  • System back-ups and other administrative tasks can be scheduled at a particular time in the day/week/month and with a specified frequency (by hour, day, week, ...):
  • DCE should enable basic analytics capabilities for the clustered deployment. DCE should gather and reconcile data from different instances and servers to be presented in a coherent manner. DCE server should introspect this information and be able to take action to heal the cluster if possible. Alarms should be configurable and be triggered on appropriate events (including the system not having the ability to automatically remedy an issue).
  • the analytics component should work based on one or more of the following threshold parameters:
  • the reporting is a key component enabling the DCE to run and service clusters autonomously. Reporting will automate essential IT processes to provide and send-out up to date information of uptime and performance of the cluster components as a whole and each individual implementation. DCE should expose this information through an API for seamless integration into other monitoring tools. Reports should also provide an overview of the installations and composition of the clusters to the system administrators.
  • Tracking usage limits (transactions, footprint, bandwidth, queries, CPU time, ... ) and providing a list of people that are approaching, going over, or over one or more of their limits.
  • Billing tracking (not a requirement for 1.0). How many resources did they consume (this needs to be automatically tracked for any billable resource).
  • This information can be used to track the adoption of the CRM system, validate the value they are getting from the system, and provide a great means of driving more adoption. If system usage of certain aspects is low, we can refer them to training resources for those aspects. When they opt out of an aspect (say customer support), we should have a system in place to track that so that we do not regularly keep suggesting to them that they make better use of the support related modules.
  • the system should provide a dashboard with all monitored Key Performance Indicators. This should have functionality similar to Sugar's reporting module. In its preferred form it will be based on the Sugar reporting and dashboard framework (with support for flash charts/graphs, tabular views, filters, printing to PDF, and export to CSV.) The following reports may be provided:
  • Alarms Alarms alert system administrators if one or many of the DCE-managed instances in the cluster are acting abnormally. Alarms should be configurable based on time/performance/resource utilization thresholds. DCE should also detect if multiple instances are having problems, log the information and aggregate multiple incidents into a few targeted alarms to avoid flooding the network if a significant outage is in progress. If there is a problem with a cluster, for instance, reporting for each instance on that cluster would flood the alarm infrastructure and hamper repair efforts. The Administrator must be able to configure watermark and time-based alarms for various system monitoring components. The System must be able to perform proactive monitoring and automated self- notification as a means to verify that:
  • Alarms should be templates that are reused. These templates should have the following parameters:
  • Escalation procedure messages might be scheduled to be sent to a specific and distinct targets based on priority, severity, lapsed time, etc.
  • the DCE may provide license management.
  • the license management functions may include:
  • DCE should have provisions to manage its own licenses. This is important when DCE is sold to other hosting providers and also as part of Sugar Enterprise edition
  • Access Control encompasses two kinds of user administration: DCE users/roles management and SugarSuite user/role management.
  • SugarSuite ACL Management

Abstract

La présente invention concerne un système et procédé d'édition de centre de traitement de données. Dans un mode de réalisation, un système logiciel d'édition de centre de traitement de données comprend une installation informatique, un ou plusieurs nœuds dans l'installation informatique, chaque nœud ayant une pluralité de dispositifs informatiques, chaque dispositif informatique fonctionnant sur une plate-forme logicielle et exécutant un déploiement d'une application logicielle sur le dispositif informatique de telle sorte que les déploiements de l'application logicielle sont répartis à travers le centre de traitement de données et l'installation informatique ayant une application d'édition de centre de traitement de données qui gère les installations de l'application logicielle répartie à travers l'installation informatique et qui offre une console de gestion d'application unifiée.
PCT/US2008/004635 2007-04-09 2008-04-09 Système et procédé d'édition de centre de traitement de données WO2008124181A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP08742728A EP2145254A4 (fr) 2007-04-09 2008-04-09 Système et procédé d'édition de centre de traitement de données

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US92260607P 2007-04-09 2007-04-09
US60/922,606 2007-04-09
US97752107P 2007-10-04 2007-10-04
US60/977,521 2007-10-04

Publications (1)

Publication Number Publication Date
WO2008124181A1 true WO2008124181A1 (fr) 2008-10-16

Family

ID=39831299

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/004635 WO2008124181A1 (fr) 2007-04-09 2008-04-09 Système et procédé d'édition de centre de traitement de données

Country Status (2)

Country Link
EP (1) EP2145254A4 (fr)
WO (1) WO2008124181A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9367490B2 (en) 2014-06-13 2016-06-14 Microsoft Technology Licensing, Llc Reversible connector for accessory devices
US9384334B2 (en) 2014-05-12 2016-07-05 Microsoft Technology Licensing, Llc Content discovery in managed wireless distribution networks
US9384335B2 (en) 2014-05-12 2016-07-05 Microsoft Technology Licensing, Llc Content delivery prioritization in managed wireless distribution networks
US9430667B2 (en) 2014-05-12 2016-08-30 Microsoft Technology Licensing, Llc Managed wireless distribution network
US9614724B2 (en) 2014-04-21 2017-04-04 Microsoft Technology Licensing, Llc Session-based device configuration
US9874914B2 (en) 2014-05-19 2018-01-23 Microsoft Technology Licensing, Llc Power management contracts for accessory devices
US10037202B2 (en) 2014-06-03 2018-07-31 Microsoft Technology Licensing, Llc Techniques to isolating a portion of an online computing service
US10111099B2 (en) 2014-05-12 2018-10-23 Microsoft Technology Licensing, Llc Distributing content in managed wireless distribution networks
US20210182162A1 (en) * 2019-12-17 2021-06-17 Infosys Limited System and method of cloning a multi-tiered application
US11372675B2 (en) * 2020-06-15 2022-06-28 Bank Of America Corporation Jobs synchronize framework
CN116756184A (zh) * 2023-08-17 2023-09-15 腾讯科技（深圳）有限公司 数据库实例处理方法、装置、设备、存储介质及程序产品

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040019889A1 (en) * 2002-04-23 2004-01-29 Secure Resolutions, Inc. Software distribution via stages
US20040068723A1 (en) * 2002-10-04 2004-04-08 Sven Graupner Automatically deploying software packages used in computer systems
US20060080656A1 (en) * 2004-10-12 2006-04-13 Microsoft Corporation Methods and instructions for patch management
US20060200860A1 (en) * 2004-10-22 2006-09-07 Jacob Taylor Team based row level security system and method
US20060253848A1 (en) * 2005-05-05 2006-11-09 International Business Machines Corporation Method and apparatus for solutions deployment in a heterogeneous systems management environment

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434744B1 (en) * 1999-03-03 2002-08-13 Microsoft Corporation System and method for patching an installed application program
US8336044B2 (en) * 2002-10-09 2012-12-18 Rpx Corporation Method and system for deploying a software image
US8387037B2 (en) * 2005-01-28 2013-02-26 Ca, Inc. Updating software images associated with a distributed computing system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040019889A1 (en) * 2002-04-23 2004-01-29 Secure Resolutions, Inc. Software distribution via stages
US20040068723A1 (en) * 2002-10-04 2004-04-08 Sven Graupner Automatically deploying software packages used in computer systems
US20060080656A1 (en) * 2004-10-12 2006-04-13 Microsoft Corporation Methods and instructions for patch management
US20060200860A1 (en) * 2004-10-22 2006-09-07 Jacob Taylor Team based row level security system and method
US20060253848A1 (en) * 2005-05-05 2006-11-09 International Business Machines Corporation Method and apparatus for solutions deployment in a heterogeneous systems management environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2145254A4 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9614724B2 (en) 2014-04-21 2017-04-04 Microsoft Technology Licensing, Llc Session-based device configuration
US9384334B2 (en) 2014-05-12 2016-07-05 Microsoft Technology Licensing, Llc Content discovery in managed wireless distribution networks
US9384335B2 (en) 2014-05-12 2016-07-05 Microsoft Technology Licensing, Llc Content delivery prioritization in managed wireless distribution networks
US9430667B2 (en) 2014-05-12 2016-08-30 Microsoft Technology Licensing, Llc Managed wireless distribution network
US10111099B2 (en) 2014-05-12 2018-10-23 Microsoft Technology Licensing, Llc Distributing content in managed wireless distribution networks
US9874914B2 (en) 2014-05-19 2018-01-23 Microsoft Technology Licensing, Llc Power management contracts for accessory devices
US10037202B2 (en) 2014-06-03 2018-07-31 Microsoft Technology Licensing, Llc Techniques to isolating a portion of an online computing service
US9367490B2 (en) 2014-06-13 2016-06-14 Microsoft Technology Licensing, Llc Reversible connector for accessory devices
US9477625B2 (en) 2014-06-13 2016-10-25 Microsoft Technology Licensing, Llc Reversible connector for accessory devices
US20210182162A1 (en) * 2019-12-17 2021-06-17 Infosys Limited System and method of cloning a multi-tiered application
US11809284B2 (en) * 2019-12-17 2023-11-07 Infosys Limited System and method of cloning a multi-tiered application
US11372675B2 (en) * 2020-06-15 2022-06-28 Bank Of America Corporation Jobs synchronize framework
CN116756184A (zh) * 2023-08-17 2023-09-15 腾讯科技（深圳）有限公司 数据库实例处理方法、装置、设备、存储介质及程序产品
CN116756184B (zh) * 2023-08-17 2024-01-12 腾讯科技（深圳）有限公司 数据库实例处理方法、装置、设备、存储介质及程序产品

Also Published As

Publication number Publication date
EP2145254A1 (fr) 2010-01-20
EP2145254A4 (fr) 2010-04-28

Similar Documents

Publication Publication Date Title
US20080276234A1 (en) Data center edition system and method
EP2145254A1 (fr) Système et procédé d'édition de centre de traitement de données
US7418489B2 (en) Method and apparatus for applying policies
JP5433084B2 (ja) 複製による、区分化されたコンテンツプラットフォーム内の固定コンテンツストレージ
US10261872B2 (en) Multilevel disaster recovery
US10146629B1 (en) Extensible workflow manager for backing up and recovering microsoft shadow copy compatible applications
KR101969604B1 (ko) 복구 서비스의 자동 구성 기법
US20060224775A1 (en) Contents synchronization system in network enviroment and a method therefor
US11604772B2 (en) Self-healing infrastructure for a dual-database system
US20230140179A1 (en) Reduced Memory Utilization for Data Analytics Procedures
Bögelsack et al. SAP S/4HANA on Google Cloud–Concepts and Architecture
Diaz et al. Working with Azure Database Services Platform
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E10702-01
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E10702-02
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E17023-09
Moore et al. ISO 16363 Infrastructure and Security Risk Management
Pot'Vin et al. Expert Oracle Enterprise Manager 12c
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E17023-08
Vallath et al. Testing for Availability
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E17023-03
Allison et al. Oracle Data Guard Broker, 11g Release 1 (11.1) B28295-01
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E17023-05
Dunphy et al. BizTalk Server 2006 Operations
Black et al. Datacenter Reference Guide
Allison et al. Oracle Data Guard Broker, 11g Release 2 (11.2) E40771-06

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08742728

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008742728

Country of ref document: EP