Step 1: Launching an Amazon
ElastiCache Cluster
Just go to AWS console, select an Amazon EC2 region and
launch a cache cluster. By default if the Amazon EC2 region is not chosen
US-EAST will be used. Provide the
following details like:
Name: This is the
Cache Identifier name and should be unique for an Amazon EC2 region(per account).
Node Type: Cache Capacity type with Memory and CPU. If you want 20 GB of distributed Cache you
can choose either 3 Cache.M1.Large or 2 Cache.M1.Xlarge Node types. Usually users
prefer Node types with more memory rather than High CPU node types (Not sure
what kind of workload needs cache.c1.Xlarge capacity on memory hungry
applications). Recently AWS has introduced Cache.M3.Class Node type which fits
Memcached kind of use cases very well. The Node type cannot be modified after
creating an Amazon ElastiCache Cluster, so please plan your base capacity in
advance with some thought. To know more about ElastiCache deployment strategies
refer URL: http://harish11g.blogspot.in/2012/11/amazon-elasticache-memcached-ec2.html
Number of Nodes: Number of Node types you want the Amazon
ElastiCache Cluster to launch. There is a limit to Cache nodes you can launch
per account. Please increase this limit using ElastiCache Limit Increase Request form.
Engine: Currently
only MemCached, I assume AWS Team will adding new cache engines in future.
Version:
Memcached 1.4.5
Cache Port: The
default port 11211 in which the Amazon ElastiCache node accepts connections.
Preferred Zone: It is the Preferred Amazon EC2 Availability
Zone in which you want to launch the Amazon ElastiCache Cluster. It is
recommended to keep the Web/App EC2 instances and Amazon ElastiCache nodes on
same Availability zone for low latency processing. In case multi-AZ is applicable your
architecture, standard Amazon EC2 Regional Data Transfer charges of $0.01 per
GB in/out apply when transferring data between an Amazon EC2 instance and an
Amazon ElastiCache Node in different Availability Zones of the same Region, you
are only charged for the Data Transfer in or out of the Amazon EC2 instance. Also
to note, currently Amazon ElastiCache Cluster cannot span across multiple Availability
zones inside Amazon EC2 region. To know more about Amazon EC2 regions and
Availability zones refer URL: http://harish11g.blogspot.in/2012/07/amazon-availability-zones-aws-az.html
Topic of SNS
notification: Lets you specify
whether you would like to receive SNS notifications related to your cache
nodes/cluster using Amazon Simple Notification Service (SNS) system. You can
either select an existing SNS topic or disable notifications completely as well
for the entire Amazon ElastiCache Cluster.
Step 2: Additional details during
launch
As part of the
additional configuration during launch process:
You may need to
configure the Cache security group and Parameter group for your Amazon
ElastiCache Cluster in this section.
The Cache security group will allow request access between your
EC2 instances and ElastiCache Nodes. The Security group of your EC2 instances
should be added in this ElastiCache Security group for opening the access. This
setting applies to all the existing and new cache nodes inside the Amazon
ElastiCache cluster. You can either create a new Amazon ElastiCache Security
group or make changes in the default security group as well. In case you have
Multitude of cache clusters with variety of EC2 tiers accessing them on various
workflows I would strongly recommend creating your own cache security groups as
best practice. Currently Amazon ElastiCache cannot be accessed outside Amazon
EC2 (It does not make sense unless you have Gigabit NW to make productive use
of Cache with low latency). Also in future, we can expect Amazon ElastiCache to
work inside Amazon Virtual Private Cloud (VPC) network as well.
Cache Parameter Group: You can either create a new parameter
group or use the default memcached parameter group. AWS provided default will
suffice for most use cases. The parameters will be applied to all the cache
nodes in the Amazon ElastiCache cluster.
Maintenance window: Amazon
ElastiCache is a Managed service and AWS team will take care of certain routine
management activities without your intervention automatically. Maintenance
window is one such period in which AWS team will carry out scheduled
maintenance like software patching in this configured time. In case your
instances are rebooted after the maintenance window period, the cache node(s)
have to be properly warmed. Since Amazon ElastiCache currently relies only on
RAM which is ephemeral in nature, such cold state is unavoidable. If you have
multiple Redundant ElastiCache clusters in Multi-AZ you can rotate the
maintenance window to your advantage and keep the cache entries warm in your
cache nodes. Refer URL: http://harish11g.blogspot.in/2012/11/amazon-elasticache-memcached-ec2.html
to know more about this technique.
Step 3: Review and Launch
Review your configuration and proceed to launch. In case any
of the details configured need to be modified you can always go back from this
screen. Usually a launch of 5 X cache.m1.large nodes in US-East will take
around ~320 seconds. This may vary time to time depending
upon the cache node type, number of cache nodes and Amazon EC2 regions in
consideration.
Related Articles
Exploring Amazon EC2 Availability Zones
Part 1: Understanding Amazon ElastiCache Internals : Connection overhead
Part 2: Understanding Amazon ElastiCache Internals : Elasticity Implication and Solutions
Part 3: Understanding Amazon ElastiCache Internals : Auto Discovery
Part 4: Understanding Amazon ElastiCache Internals : Economics of Choosing Cache Node Type
Launching Amazon ElastiCache in 3 Easy Steps
Caching architectures using Memcached & Amazon ElastiCache
Web Session Synchronization patterns in AWS
No comments:
Post a Comment