Yet Another Tridion Blog

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the ...

This post is part of a bigger topic Autoscaling Publishers in AWS . Now that we have a Launch Configuration , based on it, we can create an Auto Scaling Group. This will be in charge of creating/terminating publisher instances based on some rules (Scaling Policies). We base our Auto Scaling Group on the Launch Configuration created earlier (sdl_publisher_lc). The very important properties are the Desired, Min and Max number of instances in the group. The Desired is set usually by the Scaling Policies, but more about those later. The Min and Max are the limits of this group. In my case I use Min=1 and Max=3, meaning that I want to have 1 publisher running at all times and when needed, based on load, 2 additional publishers can be added to the group by an 'Increasing size' Scaling Policy. Once load passes, a 'Decreasing size' Scaling Policy reduces the number of instances in the group. Scaling Policies These policies represent the rules for adding/removing in...

This post is part of a bigger topic Autoscaling Publishers in AWS . Tridion Publishers need a license that matches the name of the host machine they run on. Each Publisher must have a different name. This means that when using autoscaling, we must know in advance which license to copy into the instance (at first start up time) and also we must rename that machine's hostname to match the license. This is needed because otherwise the instance machine name is always the one set in the AMI. The script below executed by the Amazon Launch Configuration service when the publisher instance starts. It is backed by a database that contains the available licenses, each with a host name. The script takes the first license available and then changes the host name to match the name specified in the license. Additionally, the script then downloads the correct license files from their s3 location and copies them in the right folder under the Tridion installation. Finally the script instruc...

This post is part of a bigger topic Autoscaling Publishers in AWS . Each Auto Scaling Group in AWS is based on a Launch Configuration. The Launch Configuration cannot be modified once it's created, but it can however be copied and modified. Once Auto Scaling is in place, the instances it creates will all be based on the specified Launch Configuration. Creating a Launch Configuration implies specifying the AMI, the Instance Type, Security IAM role, EBS drive, security group and open incoming ports. All these are AWS settings and they don't make the object of this post. What is particularly interesting is the section Configure details , subsection User data . This is where one can specify either a script of a file containing a script that will be executed inside the instance once it is created and it starts. Using this mechanism we created PowerShell scripts to configure each Publisher instance in part. <powershell> aws s3 cp s3://mybucket/scripts/publisher_user...