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.

• 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 SCO 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.

 

Our backup pattern:  

Most recent 7 days: 6 times per day. The backups will be stored for a week. 

Most recent month: 1 time per week on Saturdays. The backups will be stored for 1 month.  

After 1 month up to 6 months: 1 time per month on the first Saturday of the month.  

Any backups older than 6 months are deleted. 

 

 

Our backup pattern for non-production environments:   

Most recent 7 days: 1 time per day. The backups will be stored for a week. 

Most recent month: 1 time per week on Saturdays. The backups will be stored for 1 month. 

After 1 month up to 6 months: 1 time per month on the first Saturday of the month. 

Any backups older than 6 months are deleted.

 

Notice that restoring backup data is for emergencies only.

Disaster recovery

In the event of a disaster, the servers will, if possible, be restored in the same datacenter as before. If not, the servers will be created in an alternative data center. After the servers have been recreated all data will be restored from the latest backups. Whenever possible the Subscriber will be notified of the expected timeline for getting the server ready again. Elsevier will generally notify the Subscriber of the status and progress during the recovery process.

The current RPO (Recovery Point Objective) for Pure is 24 hours, and the RTO (Recovery Time Objective) is 8 hours.

Elsevier also has a Business Continuity Plan in place for more global emergencies (e.g., total loss of Elsevier’s Hosting Environment).

Service Windows

System Maintenance

Elsevier reserves the last weekend of each month for maintenance work on the servers. Maintenance work only includes actual maintenance on the servers, such as operating system updates or other software updates, moving servers to different hardware, etc. The service cannot, and will not, be used for updating any hosted software (this is defined in New Pure Releases, see below).

New Pure Releases

The roll out process for new versions of Pure are based on the type of release and the purchased hosting package.

Upgrades to Pure are normally performed within the following service windows, during which pure will be offline. Under normal circumstances a pure upgrade will take less than 1 hour. The Pure Portal will still be online during upgrades.

Critical Security Patches

Critical security issues will be handled on a case-by-case basis – Elsevier will assert the criticality of the issue, and will assert actions needed to remedy the issue. Elsevier will notify the customer in case Elsevier deems it necessary to act immediately upon a critical security issue. Such notification will include information on the issue that is being addressed and information on expected downtime.

Pure mail

Pure allows simple mail sending via Amazon SES. This is the default settings and it will only allow sending mails from purehosted@elsevier.com.

If wanting to use any other sender or own domain (using DKIM, SPF, DMARK or like), we cannot provide this and suggest using the Subscribers own mail system.

Pure HTTPS settings

Pure is running behind an Apache HTTPD proxy server.

It is configured to support TLS version 1.2 only and have HTTP Strict Transport Security enabled.

This is based on Mozilla's recommendation for modern browser support (See https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility for more information) which matches the @suppor supported browsers for Pure.

IPs in use for Pure and Pure Portal

These are the IPs used by Pure and Pure Portal.

If you need to setup something that make use of any of these it is recommended to use the DNS names, as that will always point to the correct IPs.

We do try to never change the IPs, but there can be instances where it is needed to be able to move to improved infrastructure.

The most likely thing to happen is that extra IPs are added to a given region to make it more robust.

We will send out notifications of any planned changes to the IPs in advance.

Outgoing IPs (NAT Gateways)

The IPs used by Pure and the Pure Portal when connecting to something on the outside of AWS.

IPs in bold are new IPs added on November 26th 2022.

Incoming IPs

The IPs used when connecting to Pure from outside AWS.

The real DNS names are not listed here, as each Pure has its own DNS name.

All new customers only get a elsevierpure.com DNS name, while a lot of old customers have both an elsevierpure.com and pure.elsevier.com DNS

name.