as PDF
Transcription
as PDF
Storage Elements in AEM 6.0 Storage Elements in AEM 6.0 Overview / Adobe Experience Manager / Adobe Experience Manager 6.0 / Deploying and Maintaining / Upgrading to AEM 6.0 / OVERVIEW OF PLATFORM CHANGES One of the most important changes in AEM 6.0 are the innovations at the repository level. Currently, there are two node storage implementations available in AEM6: Tar storage, and MongoDB storage. TAR STORAGE The Tar Micro Kernel uses tar files as storage. It stores the content as various types of records within larger segments. Journals are used to track the latest state of the repository. There are several key design principles it was build around: • Immutable Segments The content is stored in segments that can be up to 256KiB in size. They are immutable, which makes it easy to cache frequently accessed segments and reduce system errors that may corrupt the repository. Each segment is identified by a unique identifier (UUID) and contains a continuous subset of the content tree. In addition, segments can reference other content. Each segment keeps a list of UUIDs of other referenced segments. • Locality Related records like a node and its immediate children are usually stored in the same segment. This makes searching the repository very fast and avoids most cache misses for typical clients that access more than one related node per session. • Compactness The formatting of records is optimized for size to reduce IO costs and to fit as much content in caches as possible. Running a freshly installed AEM instance with Tar Storage By default, AEM 6.0 uses the Tar storage to store nodes and binaries, using the default configuration options. To manually configured its storage settings, follow the below procedure: 1. 2. 3. Download the AEM 6.0 quickstart jar and place it in a new folder. Unpack AEM by running: java –jar cq-quickstart-6.0.0.jar -unpack Create a folder named crx-quickstart\install in the installation directory. 4. Create a file called org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg in the newly created folder. 5. Edit the file and set the configuration options. The following options are available for Segment Node Store, which is the basis of AEM's Tar storage implementation: • repository.home: Path to repository home under which various repository related data is stored. By default segment files would be stored under the crx-quickstart/segmentstore directory. • tarmk.size: Maximum size of a segment in MB. The default is 256MB. 6. Start AEM. MONGO STORAGE The Mongo Micro Kernel leverages MongoDB for sharding and clustering. The repository tree is kept in one Mongo database where each node is a separate document. It has several particularities: • Revisions For each update (commit) of the content, a new revision is created. A revision is basically a string that consists of three elements: © 2012 Adobe Systems Incorporated. All rights reserved. Page 1 Created on 2015-01-27 Storage Elements in AEM 6.0 1. A timestamp derived from the system time of the machine it was generated on 2. A counter to distinguish revisions created with the same timestamp 3. The cluster node id where the revision was created • Branches Branches are supported, which allows client to stage multiple changes and make them visible with a single merge call. • Previous documents MongoMK adds data to a document with every modification. However, it only deletes data if a cleanup is explicitly triggered. Old data is moved when a certain threshold is met. Previous documents only contain immutable data, which means they only contain committed and merged revisions. • Cluster node metadata Data about active and inactive cluster nodes is kept in the database in order to facilitate cluster operations. A typical AEM cluster setup with MongoMK: Running a freshly installed AEM instance with Mongo Storage AEM 6.0 can be configured to run with MongoDB storage by following the below procedure: 1. 2. Download the AEM 6.0 quickstart jar and place it into a new folder. Unpack AEM by running the following command: 4. 5. java –jar cq-quickstart-6.0.0.jar -unpack Make sure that MongoDB is installed and an instance of mongod is running. For more info, see Installing MongoDB. Create a folder named crx-quickstart\install in the installation directory. Configure the node store by creating a configuration file with the name of the configuration you want to use in the crx-quickstart\install directory. The Document Node Store (which is the basis for AEM's MongoDB storage implementation) uses a file called org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.cfg 6. Edit the file and set your configuration options. The following options are available: 3. • • • • mongouri: The MongoURI required to connect to Mongo Database. The default is mongodb:// localhost:27017 db: Name of the Mongo database. By default new AEM 6 installations use aem-author as the database name. cache: The cache size in MB. This is distributed among various caches used in DocumentNodeStore. The default is 256 changesSize: Size in MB of capped collection used in Mongo for caching the diff output. The default is 256 © 2012 Adobe Systems Incorporated. All rights reserved. Page 2 Created on 2015-01-27 Storage Elements in AEM 6.0 • 7. 8. customBlobStore: Boolean value indicating that a custom data store will be used. The default is false. Create a configuration file with the PID of the data store you wish to use and edit the file in order to set the configuration options. For more info, please see Configuring Node Stores and Data Stores. Start the AEM 6 jar with a MongoDB storage backend by running: java -jar cq-quickstart-6.0.0.jar -r crx3,crx3mongo Where -r is the backend runmode. In this example, it will start with MongoDB support. MAINTAINING THE REPOSITORY Compacting Tar Files As data is never overwritten in a tar file, the disk usage increases even when only updating existing data. To make up for the growing size of the repository, AEM employs a garbage collection mechanism called Tar Compaction. The mechanism will reclaim disk space by removing obsolete data from the repository. Revision Clean Up By default, tar file compaction is automatically run each night between 2 am and 5 am. The automatic compaction can be triggered manually in the Operations Dashboard via a maintenance job called Revision Clean Up. To start Revision Clean Up you need to: 1. 2. 3. 4. Go to the AEM Welcome Screen. In the main AEM window, go to Tools - Operations - Dashboard - Maintenance or directly browse to http://localhost:4502/libs/granite/operations/content/maintenance.html Click on Daily Maintenance Window. Hover over the Revision Clean Up window and press the Start button. The icon will turn orange to indicate that the Revision Clean Up job is running. You can stop it at any time by hovering the mouse over the icon and pressing the Stop button: © 2012 Adobe Systems Incorporated. All rights reserved. Page 3 Created on 2015-01-27 Storage Elements in AEM 6.0 Invoking Revision Garbage Collection via the JMX Console 1. 2. 3. Open the JMX Console by going to http://localhost:4502/system/console/jmx Click the RevisionGarbageCollection MBean. In the next window, click startRevisionGC() and then Invoke to start the Revision Garbage Collection job. NOTE Due to the mechanics of the garbage collection, the first run will actually add 256 MB of disk space. Subsequent runs will work as expected and start shrinking the repository size. Offline Compaction via the Oak-run Tool For situations where normal garbage collection doesn't work, Adobe provides a manual Tar compaction tool called Oak-run. It can be downloaded here: © 2012 Adobe Systems Incorporated. All rights reserved. Page 4 Created on 2015-01-27 Storage Elements in AEM 6.0 The tool is a runnable jar that can be manually run to compact the repository. The procedure is called offline compaction because the repository needs to be shut down in order to properly run the tool. Normal operation of the tool also requires old checkpoints to be cleared before the compaction takes place. The procedure to run the tool is: 1. 2. Shut down AEM. Use the tool to find old checkpoints: java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore 3. Then, delete the unreferenced checkpoints: java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rmunreferenced 4. Finally, run the compaction and wait for it to complete: java -jar oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore © 2012 Adobe Systems Incorporated. All rights reserved. Page 5 Created on 2015-01-27