What you will find here: 

Documentation and supplementary information on hosting and installing Pure.

Amazon Web Services (AWS)

Important Reference Pages

• Privacy and Data Protection
• Data Security
• Release and Quality Assurance

Pure Cloud Hosting - AWS

Introduction

Elsevier leverages the Amazon infrastructure (AWS/EC2) for hosting of Pure. By letting Elsevier handle hosting, clients no longer need to maintain in-house knowledge on hosting and managing their own infrastructure for Pure.

This has the a lot of advantages, among others:

• Uptime. We ensure that Pure is running as expected and that the system is available according to our SLAs
• Simplifying upgrade pains. We handle all upgrades of your Pure installation.
• Server Monitoring. Your Pure installation is continuously monitored actively by our infrastructure team to ensure stability and performance of your Pure installation
• Highly Performant. We ensure that your Pure installation runs on adequately provisioned servers and continuously monitor the system performance.
• Security. All data created in Pure isolated is from other customers. The security advantages from Amazon Web Services further improves on this.
• Reduced infrastructure costs. There is no need to buy and maintain local server infrastructure, database licenses etc. As the hardware requirements for the Pure software evolve, you don't need to invest in new hardware as this is covered by us.
• Backups. All important system data is automatically backed up and kept for 26 weeks, ensuring system availability can easily be restored.

This document is not intended to cover topics already covered in our other documents:

• Privacy and Data Protection  and Data Security in context of Pure
• Release and quality assurance governing releases of Pure
• Our standard SLA - more information is available in section 4 below.

Where

We support hosting of Pure in the following AWS regions:

• US East (N. Virginia)
• EU (Ireland)
• Asia Pacific (Singapore)
• Australia (Sydney)
• China (Ningxia)

Our AWS set-up

Our typical set-up, looks like this

• Pure running on top of a Unix server (using the Amazon Linux 2 AMI)
• PostgreSQL database running on top of a Unix server (using the Amazon Linux 2 AMI)
• Front-end in form of a Apache server running on top of a Unix server (using the Amazon Linux 2 AMI)
• Pure Portal running on top of a number of Unix servers in multi-AZ setup for fault tolerance, with Cassandra and ElasticSearch backends for storage and search (using the Amazon Linux 2 AMI)

As described in the section on Service Windows (See section 12 below), we will perform maintenance upgrade of the underlying Unix Server (the Amazon Linux 2 AMI), as well as perform "ad hoc" patching as need when critical security updates are released for the specific Linux distribution we use. All servers are monitored (See section 7.2 below) and all modifiable data (databases, files, configuration, etc) are backed up regularly (See section 10 below).

You can read more about the Amazon Linux AMI here: http://aws.amazon.com/amazon-linux-ami/

We use (in Q1 2022) a mixture of m5a.xlarge, m5a.2xlarge and m5a.4xlarge instance to host the various parts of Pure (web-apps, database, file-system, services, etc).

SLA

Our SLA covers the following general topics and service levels. The points in bold, is already included in this document. Further SLAs are found in Service Level Agreement.

• Mailing lists
• Help Desk services
• Error Reporting
• Categorization of Defects
• Remediation times in relation to error reporting
• Escalation of errors
• System response times
• System operational and availability guarantees 
• Procedures in case of lacking availability
• Warranty regarding availability
• Security
• Storage and Backup
• System Maintenance Windows
• Disaster recovery
• Backup procedures
• Monitoring

Our SLA is a standard SLA for all customers, however, it does evolve over time - depending on new needs and/or changes in the infrastructure. Evolution is strictly "inclusive", hence we do not plan to relax service levels over time, nor discontinue certain service levels. What we do plan is to, over time, introduce more services levels, and in general strengthen the hosting offering - while adhering to our hosting principle as outlined above.

We are happy to share a copy of our current standard SLA with any customers, or potential customers.

Certificates

We are ISO27001 certified  (view our certification) , and we have defined procedures for Privacy and Data Protection, Data Security and Release and quality assurance.

Furthermore, our hosting partner, Amazon Web Services (AWS), holds an ISO 27001 certificate, which, along with their SOC 1 and SOC 2, can be made available to our active Pure customers on request to Elsevier. Note that any reports shared will be confidential, in accordance with your Pure agreement. AWS also holds an ISO 9001 certificate, and their SOC 3 is publicly available.

You can read more on Amazon's compliance here: http://aws.amazon.com/compliance/

Security

Please read our procedures for Data Security .

All servers will be behind an Apache HTTPD server and will only be accessible through HTTPS (SSL). All servers are behind a firewall with only port 80 and port 443 open. Port 80 will only be used to redirect client to port 443 so they do not get an error if trying to access the Subscribed Products with HTTP instead of HTTPS.

• All access to the internal network will be through VPN, so the traffic will always be encrypted
• All database users (one per customer) will have unique passwords and all relevant elements of the Subscribed Products is run as an Authorized User, without administrator rights

Our security is subject to change - please consult the latest version of our SLA for our current security measures.

System operational and availability guarantees

Elsevier warrants that the System shall have a yearly Availability of at least 99.5% - excluding scheduled maintenance. Furthermore, downtime excluded from availability includes Critical Security Patches, Permitted Maintenance and any disruptions in the availability of the System or reduced availability caused by problems beyond Elsevier’s control (e.g. force majeure or network problems) or caused by the Subscriber’s own equipment or applications.

Our System operational and availability guarantees are subject to change - please consult the latest version of our SLA for our current security measures.

Procedures in case of lacking availability

If either party discovers lacking availability, they must inform the other party hereof, without undue delay. 
Elsevier shall commence work to re-establish availability, no later than the morning of the next working day. Elsevier shall inform the Subscriber in writing when work to re-establish availability has been initiated, and again when availability has been re-established.  
When availability has been completely re-established Elsevier shall send a written report detailing the cause and responsibility for the incident, as well as a short summary of the incident, to the Subscriber.

Please consult the latest version of our SLA for information on warranty regarding availability.

Monitoring

All production servers hosted by Elsevier, will be registered in Elsevier’s monitoring software, which runs at regular intervals, 24 hours a day in order to ensure that any system malfunctions are detected, and that relevant people are alerted. We have different escalation procedures in place depending on the severity of the alert. Specifically the monitoring software will log response times, and alert Elsevier if the response times are too high - including checking that Pure can reached through the web interface, and that the Java / Tomcat process is running. The monitoring software will also monitor disk usage, memory usage, CPU usage, and all required services related to the OS. Furthermore, the monitoring software also checks that the backups have run correctly every night.

Our monitoring setup also provide us with statistics on "performance" and up-time of our different servers - we plan to make these statistics available for our customers as a "downloadable" report in the future.

Performance

Performance of our Pure servers is constantly monitored, and in the event of performance issues we use the means available in AWS to alleviate such problems. Specifically by changing instance types, provisioned IOPS, EBS "optimisations", and so on. In extreme cases we even have the option of running the individual Pure applications (Admin, Portal, WS) on different servers, or running on a dedicated database server.

The Pure architecture does not support traditional load balancing (nor, is it relevant). However, we are constantly testing and benchmarking Pure as part of our development process - this allows us to spot potential performance degradation as part of the introduction of new features, or as a result of changes in general.

Storage

Hosting shall include storage of up to 1 TB front end data, including, but not limited to, the database, upload files, audit logs, etc. Should the Subscriber exceed this limit, Elsevier shall contact the Subscriber, to agree any needed changes to the Agreement. Any changes to the storage limit shall be agreed in writing between the parties, and may be subject to additional fees. 

The Subscriber shall endeavor to inform Elsevier before uploading more than 100 GB of data in any one week.

Backup

We perform a backup of all data stored in Pures database, file system and configurations - i.e. this covers all modifiable data in Pure.