Beruflich Dokumente
Kultur Dokumente
This document provides minimum system requirements and guidelines for running Alliance Access 7.1 and higher.
22 July 2016
Alliance Access
System Configuration Recommendations and Guidelines Table of Contents
Table of Contents
Preface......................................................................................................................................................3
1 Introduction.................................................................................................................................... 4
2 Reference Platforms...................................................................................................................... 5
3 High-End Systems......................................................................................................................... 7
3.1 FIN Test Configuration...................................................................................................................8
3.2 CPU Usage for FIN Traffic............................................................................................................. 8
3.3 InterAct Test Configuration............................................................................................................ 9
3.4 CPU Usage for InterAct Traffic.................................................................................................... 10
3.5 FileAct Test Configuration............................................................................................................13
3.6 CPU Usage for FileAct Traffic......................................................................................................13
Legal Notices......................................................................................................................................... 28
22 July 2016 2
Alliance Access
System Configuration Recommendations and Guidelines Preface
Preface
Purpose
The purpose of this document is to provide the following information:
guidelines for minimum system requirements on which to run Alliance Access 7.1 and higher
with the following committed throughputs:
- up to 40, 20, 10, and 5 Transactions Per Second (UNIX and Windows)
an outline of the impact on CPU usage when processing these throughputs
guidelines for disk space sizing
outline the effect of usage of certain features on system resources
Intended audience
This document is intended for new and existing customers who require recommendations for
sizing a system that is capable of handling a certain message throughput.
Significant changes in this version
This document has been updated to:
Remove the measurements for Power 6 machines, as they are no longer available in the list
of hardware requirements on swift.com.
Add the measurements for Power 8 machines on Alliance Access 7.1.
References to Oracle Sun servers
The graphics in this document that are labelled Sun (for example, Sun M4000) refer to Oracle's
Sun SPARC Enterprise M-Series Servers.
Related documentation
You can find a full list of related documents in the Documentation section of the Alliance Access
Release Letter.
22 July 2016 3
Alliance Access
System Configuration Recommendations and Guidelines Introduction
1 Introduction
Overview
Section Describes
Reference Platforms The reference platforms that were used to perform the benchmarking
tests.
Low-End and Medium-End Information about systems running 5 or 10 Transactions Per Second.
Systems
CPU usage was compared between running 5 or 10 Transactions Per
Second.
Disk Sizing Guidelines Guidelines for disk sizing for FIN, InterAct, and FileAct messaging
services.
Impact of Specific Activity Information about the impact of recovering the database.
General guidelines are provided to minimise the recovery time and to
configure the mirror and backup disks. Furthermore, the impact on
system resources when running a full recovery backup was measured.
This was performed on the reference platforms for a throughput of 40
FIN Transactions Per Second.
22 July 2016 4
Alliance Access
System Configuration Recommendations and Guidelines Reference Platforms
2 Reference Platforms
Overview
The reference systems are available on www.swift.com, under Products & Services >
Introducing SWIFTNet 7.0 and Alliance 7.0 > Details > Hardware requirements for release 7.0.
Reference systems are available for running the following scenarios:
Alliance Access up to 40 TPS
Alliance Access up to 20 TPS
Alliance Access up to 10 TPS
Alliance Access up to 5 TPS
all SWIFT software (that is, SWIFTNet Link, Alliance Gateway, Alliance Access/Entry, and
Alliance Web Platform) on one system (for less than 1000 messages per day).
The hardware memory requirements on swift.com have been updated for 5 TPS systems, as
well as for systems with two or more SWIFT software packages installed on the same server.
You must contact SWIFT if your institution requires a TPS greater than 40 TPS.
Additional CPUs, RAM, and storage capacity
You must also consider additional CPUs, RAM, and storage capacity on top of the hardware
requirements provided, if the following circumstances apply to your institution:
Multiple back-office connections are used (for example, file based message partners).
More complex routing is defined (multiple instances per message, additional interventions).
Additional services provided on messages by means of IPLA components or ADK
applications.
The system is also used by operators to search for messages and events in the database.
Disk configuration for high-end systems
For high-end systems, the disk configuration must have enough persistent write cache.
Disk striping is highly recommended (for example, RAID 0, RAID 5, RAID 6). The selection of
the level depends on performance, resiliency, and cost considerations.
The bandwidth between the Alliance Access host and the disk subsystem must be adequate
and guaranteed.
If you use synchronous replication, then ensure that this has the least possible impact on the
disk performance and ensure that sufficient bandwidth is available between the locations.
If you use asynchronous replication, then the technology used must ensure dependent-write
order consistency across the Alliance Access file systems. Data can be lost in a disaster
situation, which can result in messages being sent twice without a Possible Duplication
Emission (PDE) trailer.
Note As measured by the disk_test tool on Alliance Access, the global disk
performance on SWIFT reference systems is under one second. You can find the
tool in $ALLIANCE/common/bin/$ARCH/disk_test on UNIX or %ALLIANCE%
\common\bin\%ARCH%\disk_test.exe on Windows.
22 July 2016 5
Alliance Access
System Configuration Recommendations and Guidelines Reference Platforms
22 July 2016 6
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
3 High-End Systems
Overview
This section provides data for systems running 20 or 40 Transactions Per Second.
The section first describes the test configuration implemented on the benchmarking platforms.
Then, it gives a summary of the impact on CPU when running Alliance Access 7.1 and higher at
20 or 40 Transactions Per Second.
Alliance Access is configured to process quickly a large volume of messages that are
exchanged with back-office applications (with no system interventions on the system, some
events disabled). For more information, see Knowledge base tip 5017911. The messages
received from the back-office applications are sent directly to the SWIFT interface. The
messages received from SWIFT and the transmission notifications are sent directly to the back
office.
Alliance Access disk configuration
Benchmarks tests were run with the Alliance Access release tree and database on a single file
system. If maximum performance is targeted, or if input/output is identified as a bottleneck, the
following distribution may enhance performance (the redo logs are most critical for
performance). Note that, for resiliency reasons, the Database Recovery disks should always be
configured on different physical storage.
22 July 2016 7
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
22 July 2016 8
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
22 July 2016 9
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
messages. For this test, when using the MQ Host Adapter, the MQ queues are configured in
non-persistent mode and the system is running in MQ client mode. The XMLv2 message
format is used.
For the tests with 20 Transactions Per Second, divide by 2 the numbers in these results.
22 July 2016 10
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
22 July 2016 11
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
22 July 2016 12
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
22 July 2016 13
Alliance Access
System Configuration Recommendations and Guidelines High-End Systems
Measurements for Power 8 and Linux were made for 10 TPS FileAct using the MQHA and
SOAPHA adapters in full mode, using a high-end configuration.
Note The CPU numbers in these results are the maximum observed values for sending
concurrent files to the local simulator.
Therefore, this does not reflect the impact of the bandwidth nor the time needed for
processing on the central system. The CPU values of sending the traffic through
the SWIFT network are expected to be much lower based on the actual network
transient time and the number of Alliance Gateway connections that are used.
22 July 2016 14
Alliance Access
System Configuration Recommendations and Guidelines Low-End and Medium-End Systems
22 July 2016 15
Alliance Access
System Configuration Recommendations and Guidelines Low-End and Medium-End Systems
22 July 2016 16
Alliance Access
System Configuration Recommendations and Guidelines Low-End and Medium-End Systems
On all platforms, the CPU average load increases when traffic increases from 5 to 10
Transactions Per Second, although this is not linear.
Note The 5 TPS figures on the POWER 7 system have been extrapolated.
22 July 2016 17
Alliance Access
System Configuration Recommendations and Guidelines Low-End and Medium-End Systems
22 July 2016 18
Alliance Access
System Configuration Recommendations and Guidelines Low-End and Medium-End Systems
22 July 2016 19
Alliance Access
System Configuration Recommendations and Guidelines Low-End and Medium-End Systems
Note The CPU numbers reached are the maximum observed when sending 30
concurrent files to the local simulator.
Therefore, this does not reflect the impact of the bandwidth nor the time to process
on the central system. The values reached when sending the traffic through the
SWIFT network are expected to be much lower based on the actual network
transient time and the number of Alliance Gateway connections that are used.
22 July 2016 20
Alliance Access
System Configuration Recommendations and Guidelines Disk Sizing Guidelines
daily journal 16 MB 64 MB
Depending on the configuration and the messaging service (FIN, InterAct or FileAct), the size of
the message can affect the amount of disk space that is required for the datafile. For low daily
volumes, the initial size of the datafiles should be enough.
This sizing represents the minimal space usage, based on an Alliance Access server with low-
end configuration (default routing and interventions) and 2 instances per input message, and 1
instance per output message.
Note All calculations are very conservative and have been done considering the worst
case scenario (last extent barely used and using a low-end configuration). If your
institution requires more complex routing or additional message instances, then
more space will be required. In that case, contact SWIFT.
Archives
With Alliance Access 7.1 and higher, the daily message archives are still stored in the database.
These archives can occupy approximately up to 10 percent more disk space than the original
day of traffic (depending on the traffic distribution across the messaging services FIN, InterAct,
and FileAct). This extra disk space is required for additional data created to improve the
performance of message searches in archives. On the other hand, once the daily table is
archived, the daily table will be resized to only use the necessary disk space (the same applies
to restored archives).
Backups
During the backup operation, the archived messages are backed up to external files. During
operations to remove backups, the archived messages are backed up to external files and then
they are removed physically from the database. The space occupied by the backup of a
message archive on the external file system is approximately 40 percent less than the disk
space occupied by the live original day of traffic (depending on the traffic distribution across the
messaging services FIN, InterAct, and FileAct) stored in the database.
22 July 2016 21
Alliance Access
System Configuration Recommendations and Guidelines Disk Sizing Guidelines
Concepts
To use the formula properly for calculating the disk space for messages, the following concepts
are important
LOB segment: If the size of the message payload is below 4 KB, then the message payload will
be stored in-line. Therefore, the space occupied is equal to the actual size of the payload. If the
size of the message payload is greater than or equal to 4 KB, then the message payload will be
stored in segments of 8 KB. For example, a payload of 10 KB will be stored in 16 KB (two 8 KB
segments).
Message overhead: Based on our calculations, each message that is stored in the database
will have an overhead of 10 KB. This is for a low-end configuration and is a conservative
guideline.
Adjusted table size: For daily messages, the initial size of the daily datafile will be 32 MB with
additional extents of 128 MB. This means that 130 MB of data will be stored in 160 MB (initial
size plus the next increment)
Formula
Disk Space (MB) = Adjusted table size [msg overhead (KB) + adjusted payload (KB)] x # msgs / 1024
The following table shows the average space allocated for live messages based on the number
of messages per day:
Note For a high-end configuration, the sizing will require less space because less
information is stored for messages in the daily datafiles.
22 July 2016 22
Alliance Access
System Configuration Recommendations and Guidelines Disk Sizing Guidelines
Disk Space (MB) = Adjusted table size [event overhead (KB) + adjusted payload (KB)] x # msgs / 1024
The following table shows the average space allocated for the event journal based on the
number of messages per day and the payload being logged (FIN only):
Disk space (in MB) required for events for FIN message flow
22 July 2016 23
Alliance Access
System Configuration Recommendations and Guidelines Disk Sizing Guidelines
Formula
This formula is for the Event Journal for FIN or MX traffic message flow with a low-end
configuration, and when a message payload is not logged:
Disk Space (MB) = Adjusted table size [event overhead (KB)] x # msgs / 1024
The following table shows the average space allocated for the event journal based on the
number of messages per day and the payload is not logged (FIN and MX):
Disk space (in MB) required for events for FIN or MX message flow (no payload logged)
Note For a high-end configuration, the sizing required for FIN or MX message flow will
be 16 MB (initial increment), as no message flow events are logged.
22 July 2016 24
Alliance Access
System Configuration Recommendations and Guidelines Disk Sizing Guidelines
Adjusted table size (daily messages datafile): For daily messages, the initial size of the daily
datafile will be 32 MB with additional extents of 128 MB. This means that 130 MB of data will be
stored in 160 MB (initial size plus the next increment).
Formula for FileAct messages (daily message datafile)
Disk Space (MB) = Adjusted table size [msg overhead (KB) + adjusted HeaderInfo (KB)] x # msgs / 1024
The following table shows the average space allocated for the FileAct live messages based on
the number of messages per day:
Disk Space (MB) = Adjusted table size [FileAct overhead (KB) + adjusted payload (KB)] x # msgs / 1024
The following table shows the average space allocated for the FileAct payload files based on the
number of messages per day:
Note It is possible to define per service if the FileAct payload files should be archived,
should not be archived (existing), or should be deleted immediately. This is taken
into account in the above formula to calculate the number of messages.
22 July 2016 25
Alliance Access
System Configuration Recommendations and Guidelines Impact of Specific Activity
In general, the time needed to recover an Alliance Access database can be influenced as
follows:
Using compression for the recovery backup, which is an optional parameter, significantly
increases the time to recover. When compressing a backup of a database of 1 million
messages, the disk space required for this backup is compressed from 9.2 GB to 2.5 GB.
Including archive backups in the recovery backup, which is optional, increases the time to
recover.
Excluding archive backups in the recovery backup on a system with many archive backups
(in thousands), would increase the time to recover by approximately 3 seconds per archive
backup.
The figures in the table in this section are valid when recovering from a full recovery backup.
When the recovery is done either from incremental backups only or from redo logs only, this
influences the recovery time as follows:
Recovering from a full recovery backup is faster than recovering from incremental backups.
Recovering from incremental backups is faster than recovering from the redo logs.
Taking a full recovery backup
To limit the impact of a creating recovery backup on the system performance, a new
configuration parameter Maximum Read Rate is available. This parameter specifies the disk
input/output (expressed in MB/sec) that can be used when a recovery backup is created.
22 July 2016 26
Alliance Access
System Configuration Recommendations and Guidelines Impact of Specific Activity
When this parameter is set to zero (maximum I/O usage), there is no limitation on the disk I/O
that is used. In that case the time required to take a full recovery backup is equivalent to the
time that it takes to restore the database (see the table in the section Time to recover above).
If you set the Maximum Read Rate parameter to 30, then the time that it takes for the backup to
complete is doubled on all platforms. However, the time depends on the disk infrastructure.
Note SWIFT advises you test other values for this parameter in addition to 30.
CPU impact
When activating the database recovery option, the increase in CPU is minimal. The biggest
increase is observed when the full recovery backup is being taken and the read rate is set to the
maximum. Even in this condition, the increase observed during our tests never exceeded 10
percent.
Mirror and backup disk
The mirror disk is used to mirror the redo logs. Updates on the database are written
simultaneously on the live disk (Online Redo Log) and the recovery mirror disk (Mirrored Redo
Log).
As the database transaction only commits when both disks are updated, it is important that the
recovery mirror disk is as fast as the live disk to avoid a slowdown of the data updates. The size
of this disk must be sufficient to store the three redo logs and one control file.
The recovery backup disk stores the different database backups and the archived redo log files.
Therefore, this should be a large-storage disk, with a size that is three times the size of the live
database. This should only be considered as a rule of thumb, as the actual disk size depends
on a number of parameters such as the daily traffic volume and the database recovery
configuration. The speed of this disk is less important than the speed of the recovery mirror
disk.
22 July 2016 27
Alliance Access
System Configuration Recommendations and Guidelines Legal Notices
Legal Notices
Copyright
SWIFT 2016. All rights reserved.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order
expressly grants you that right, in which case ensure you comply with any other applicable
conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the
latest available version.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT:
the SWIFT logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo,
MyStandards, and SWIFT Institute. Other product, service, or company names in this
publication are trade names, trademarks, or registered trademarks of their respective owners.
22 July 2016 28