Hardware sizing recommendations hardware-sizing-reco
Overview
This document provides general recommendations for ۶Ƶ Campaign Classic v7 deployment at your on-premise data center or virtualized cloud environment. This type of deployment, referred to as hybrid or mid-sourcing, places the Campaign marketing instance and marketing database under your operational control, while using ۶Ƶ Cloud Messaging services to send emails, SMS or SMPP messages, and collect email open, bounce, and click tracking data.
The marketing instance is the portion of the ۶Ƶ Campaign architecture that drives all marketing activity, and stores all recipient data and analytic data returned by campaigns. The marketing instance is a set of on-premise servers running ۶Ƶ Campaign services, and a relational database.
Software compatibility is detailed in the Compatibility Matrix.
Scenarios
Deployment diagrams and hardware sizing recommendations are provided for three representative scenarios:
- Moderate-Size – 5 millions active recipients in the system
- Large-Size – 20 million active recipients in the system
- Enterprise – 50 million active recipients, with transactional messaging
Assumptions
This document also assumes the following types of usage for all three scenarios:
- Large email campaigns are sent twice a week, to approximately 50% of your active recipients
- Direct mailings are generated once per month for each recipient in the system
- SMS messages are sent to approximately 10% of your active recipients each month
- The database schema defining each recipient has been extended with one additional table, containing about 200 bytes of data for each recipient
- ۶Ƶ Campaign Interaction module is used to add offers to outgoing email
- Email tracking data is retained in the Campaign system for 90 days
General guidelines
Campaign is a database-centric application, and database server performance is critical. Running workflows, segmentation, tracking data uploads, inbound Interactions, analytics and other activities all generate database activity. In general, the size and frequency of these operations determine the size of your database servers.
The application servers in your marketing instance require enough CPU and memory to run workflows and respond to SOAP API calls, including requests from Campaign Console users. CPU requirements can be significant for workflows that use outbound interactions with complex offer rules, workflows that execute custom Javascript, and web applications with high traffic levels.
Campaign web applications can also be deployed on the marketing instance App servers, or on separate web server systems. Since web application workloads conflict with critical workflows and Campaign Console users, web applications and inbound interactions can be deployed to separate servers, to ensure that core Campaign functionality runs reliably with good performance.
For security and availability, ۶Ƶ recommends separating the traffic of the Internet from the traffic generated by the business users. For that reason, the diagrams contain two groups of servers: the Web server (Internet facing Web1 and Web2), and the App servers (business processes App1 and App2).
It is a legal requirement for commercially email senders to have a functional opt-out web page. ۶Ƶ recommends having redundant machine in each group server for fail-over scenarios. It is especially true if ۶Ƶ Campaign hosts the opt-out pages.
Reverse proxies
The Campaign architecture enforces high security by using SSL over HTTP (HTTPS) to communicate between your marketing instance and ۶Ƶ Cloud Messaging. Security, reliability, and availability are enforced by using reverse proxies in a “demilitarized zone” (DMZ) subnet to isolate and secure the marketing instance servers and database.
Load balancer
The load balancer for the App servers is set up in an active/passive configuration, with HTTPS terminated at the proxy. The load balancer for the Web servers is set up in an active/active configuration, with HTTPS terminated at the proxy.
۶Ƶ provides you with the exclusive list of URL paths that can be relayed to the ۶Ƶ Campaign server in your deployment environment.
Architecture
The general architecture is almost identical regardless of the volumes. The security and high availability requirements dictate a minimum of four servers; two servers if no WebApps are used. The difference in the configuration mainly varies in the hardware configuration like CPU core and memory.
Scenario 1: Moderate-Size Deployment scenario-1
Estimated volume:
For these volumes, a pair of ۶Ƶ Campaign application server systems provides all functionality for ۶Ƶ Campaign Client users and workflow execution. For 5 millions active recipients and this email volume, application server workloads are not CPU or I/O intensive; most of the stress is on the database.
The ۶Ƶ Campaign Web servers are shown in the secure zone.
Web & Application Servers
This scenario recommends installing ۶Ƶ Campaign on four machines, with the following specification:
3Ghz+ quad-core CPU, 8-GB RAM, RAID 1 or 10, 2 x 80-GB SSD
These systems create the marketing instance Application Server, which directly supports your Campaign Console users and executes the campaign workflows.
Reverse proxies in a DMZ load balance traffic to the ۶Ƶ Campaign Web servers. There is no requirement to install the ۶Ƶ Campaign software stack on proxy machines; any reverse proxy software or network equipment can be used.
Subscription opt-in/opt-out and preference center features can be provided by Campaign or by your own website. If you choose to implement this functionality on your website, you must ensure that preference and subscription information is propagated to the Campaign marketing database. It is normally done by creating extraction files which are uploaded by Campaign workflows automatically.
Disk space consumption on Application Servers depends on the retention period of files exchanged with third-party service providers (for example, print vendors for Direct Mail), and on the size and retention of imported flat files, like subscription or preference updates from your website, or extracts from your own CRM or marketing systems.
Database
Hardware recommendations for the database server are as follows:
3Ghz+ 4-core CPU, 16-GB RAM, RAID 1 or 10, 128GB SSD minimum
The memory estimate assumes full caching of approximately 500,000 recipients for a large campaign launch, plus RDBMS buffer space for executing workflows, importing tracking data, and other concurrent activities.
It is estimated that the disk space required on the database to store all ۶Ƶ Campaign technical data (campaigns, tracking, working tables, and so on) is approximatively 35 GB based on a retention period of three months. If you choose to retain tracking data for 6 months, database size increases to approximatively 40 GB, and 12-month retention increases database size to approximatively 45 GB. Recipient data consumes about 5 GB for this environment.
Also consider that due to the volume of information processed daily, the IOPS of the database server is critical. For example, on a peak day, you can deploy campaigns targeting a total of 500,000 recipients. To execute each campaign, ۶Ƶ Campaign inserts 500,000 records into a table containing roughly 12 million records (the delivery log table). To provide acceptable performance during the campaign deployment, ۶Ƶ recommends a minimum of 60,000 4-KB Random read/write IOPS for this scenario.
Scenario 2: Large-Size Deployment scenario-2
Estimated volume:
Web & Application Servers
In this scenario, ۶Ƶ recommends installing ۶Ƶ Campaign on four machines, two application servers and two web servers, with the following specification:
3Ghz+ quad-core CPU, 8-GB RAM, RAID 1 or 10, 80-GB SSD
The Application servers directly support Campaign Console users and the execution of campaign workflows. This functionality is deployed on two identical servers for high-availability, sharing a Network-Attached Storage (NAS) file system to enable failover.
The Web servers host Campaign web applications supporting the 10-million active recipients in the system.
Refer to Scenario 1: Moderate-Size Deployment for more comments on proxies, preference centers/subscription handling, and disk space usage.
Database
Hardware recommendations for the database server are as follows:
3Ghz+ 8-core CPU, 64-GB RAM, RAID 1 or 10, 2 x 320-GB SSD or RAID 10, 640 GB SSD minimum
The memory estimate assumes full caching of approximately 5,000,000 recipients for a large campaign launch, plus RDBMS buffer space for executing workflows, importing tracking data, and other concurrent activities.
It is estimated that the disk space required on the database to store all ۶Ƶ Campaign technical data (campaigns, tracking, working tables, and so on) is approximatively 280 GB based on a retention period of 3 months. If you choose to retain tracking data for 6 months, database size increases to approximatively 450 GB, and 12-month retention increases database size to approximatively 900 GB. Recipient data consumes about 15 GB for this environment.
Scenario 3: Enterprrise Deployment with Message Center scenario-3
Estimated volume:
The deployment supporting 50 million recipients is essentially the same as shown in Scenario 2: Campaign web application traffic is routed to Campaign web servers, so the bursts of web traffic after large campaign launches does not impact Campaign workflows and Client Console users.
This deployment also includes Message Center calls, driven from your own websites and applications.
Web & Application Servers
In this scenario, ۶Ƶ recommends installing ۶Ƶ Campaign on four machines, as follows:
-
Application servers
Two systems, 3Ghz+ quad-core CPU, 8-GB RAM, RAID 1 or 10, 80-GB SSD -
Web servers
Two systems, 3Ghz+ quad-core CPU, 16-GB RAM, RAID 1 or 10, 80-GB SSD
The Application servers directly support Campaign Console users and the execution of campaign workflows. This functionality is deployed on two identical servers for high-availability, sharing a Network-Attached Storage (NAS) file system to enable failover.
The Web servers host Campaign web applications supporting the 10-million active recipients in the system.
Refer to Scenario 1: Moderate-Size Deployment for more comments on proxies, preference centers/subscription handling, and disk space usage.
Database
Hardware recommendations for the database server are as follows:
3Ghz+ 8-core CPU, 96-GB RAM, RAID 1 or 10, 1.5TB SSD minimum
The memory estimate assumes full caching of approximately 12,500,000 recipients for a large campaign launch, plus RDBMS buffer space for executing workflows, importing tracking data, and other concurrent activities.
It is estimated that the disk space required on the database to store all ۶Ƶ Campaign technical data (campaigns, tracking, working tables, and so on) is approximatively 700 GB based on a retention period of 3 months. If you choose to retain tracking data for 6 months, database size increases to about approximatively 1.2TB, and 12-month retention increases database size to approximatively 2TB. Recipient data consumes about 50 GB for this environment.
Guidelines for Changing Assumptions
The assumptions made for these scenarios all have a significant impact on the hardware recommendations and deployment architecture. This section discusses guidelines around different assumptions. Contact the ۶Ƶ Campaign Consulting team for specific recommendations to meet your requirements.
-
Number of Recipients
Active recipients require both storage space and database buffer space, so more recipients generally require more memory and CPU capacity on the database server. Storage increases are relatively small for the recipients themselves, but can ay be significant for the event tracking data kept for email campaigns. -
Email Campaign Size
The frequency of campaign launches has an impact on database server CPU requirements. Combined with direct mailing, inbound Interactions, and other workflows, segmentation operations for email campaigns put a significant load on the database server. -
Direct Mail Frequency
The frequency of direct mailings can impact database server CPU requirements. Combined with campaign launches and other workflows, segmentation operations for direct mailings put a significant load on the database server. -
SMS Message Volume
Like email campaign size, SMS message volume does not place large loads on Campaign servers located on-premise; the load is mostly on ۶Ƶ Cloud Messaging servers on the cloud. Segmentation for SMS campaigns, like email and direct mail, can place a significant load on the marketing database. Therefore the frequency of SMS campaign launches and complexity of segmentation are more relevant than the volume of SMS messages. -
Database Schema Complexity
The amount of data for each active recipient requires both storage space and database buffer space, so more recipients generally require more memory and CPU on the database server. Complex schemas also require more tables to be joined for segmentation, so segmentation operations can run much slower, and require more database CPU and memory when data is spread across multiple tables.Database server memory is estimated by ensuring that the database buffer pool can be large enough to contain all recipient data, plus temporary tables for running workflows, plus a margin for other database operations.
-
Outbound Interaction Usage
Rules for Interaction in batch mode are evaluated in workflows that hand over all the calculation complexity to the database. The main factor of effort on the database is the total number of eligible offers computed during one engine call (target size X average number of offers per recipient before keeping the N best offers). The database server CPU speed is the first factor of performance. -
Inbound Interactions or SOAP API Usage
Inbound Interaction rules and offers are evaluated in the marketing database, requiring significant database server resources, especially CPU. Heavy usage of inbound Interactions or SOAP APIs requires separate web servers to separate the work load from running Campaign workflows. -
Tracking Data Retention Period
Increasing the retention of tracking data beyond 90 days requires more database storage, and can slow down the system because inserting new tracking data goes into large tables. Tracking data is not useful for campaign segmentation after 90 days, so the shorter retention period is recommended.Tracking data should be moved into ۶Ƶ Analytics or another analytics system if you require long-term analysis of recipient marketing experience.
Virtualization
All Campaign servers are good candidates for virtualization. Several issues must be addressed to ensure appropriate availability and performance.
-
Fail-Over Configuration
Clustered servers, for example, redundant application servers under a load-balanced proxy, must be deployed on separate hardware to ensure that both VMs do not go down if there is hardware failure. -
I/O Configuration
Any recommended RAID configuration must be maintained for database security, to ensure that loss of a storage device does not cause loss of data. -
I/O Performance
The recommended IOPS rating for database storage must be respected. Cloud services like Amazon EC2 may not provide the required performance, and must be carefully evaluated. For example, Amazon EC2 provisioned SSD volumes are currently rated at 20,000 IOPS each. Learn more in ), so a 4-volume RAID configuration would be rated at 80,000 IOPS, which may not be sufficient.
۶Ƶ recommends performance testing for any virtualized deployment of ۶Ƶ Campaign before putting the system into production.