Update CFN to allow starting of i2.2xlarge ES nodes

[dpb587]

From @mrdavidlaing:

@dpb587, these are the CFN changes I made to the existing cityindex.logsearch.io cluster to enable running i2.2xlarge nodes; specifically

live-logsearch-ElasticsearchDaytimeGroup-AFCJ72SHXWNK live-logsearch-ElasticsearchFulltimeZone1Group-6SYZH3M84SRR live-logsearch-ElasticsearchFulltimeZone2Group-1TWREYORFN1AZ However, I'm struggling to identify the correct source files to update. Please can you help.

Also, I had to update the Ubuntu AMI to one based on the HVM hypervisor, since i2.* nodes don't run on the older PV hypervisor.

This commit is more of a conversation starter than a finished bit of work.

[sopel]

@mrdavidlaing - I'm not following along, you seem to have updated the correct file already? Either way I suggest to apply such structural changes systematically (see e.g. #229 and #314), here's what I'd do to find affected files:

$ git grep -i m3.large
.build/aws/cloudformation/composite-example-standalone.template:      "m3.large" : {
.build/aws/cloudformation/group-elasticsearch-default.template:        "m3.large",
.build/aws/cloudformation/group-logstash-default.template:        "m3.large",
.build/aws/cloudformation/node-es-ebs-default.template:        "m3.large",
.build/aws/cloudformation/node-es-ephemeral-default.template:        "m3.large",
.build/aws/cloudformation/node-kibana-default.template:        "m3.large",
.build/aws/cloudformation/node-redis-default.template:        "m3.large",

However, as you already pointed out, the i2 instance types require a HVM image, whereas most others do not (some already do in fact, e.g. I've erroneously added the similarly constrained GPU instance types w/o addressing this) - to properly reflect this, we might need to add a respective AMI mapping.

[sopel]

Given the c3.* instance family supports both PV and HVM images and requires a resp. decision (to avoid yet another and non orthogonal parameter just for that), I've tried to figure out the performance difference/impact once again:

• AWS Virtualization : HVM vs Paravirtualization procides a summary of the subject matter from a virtualization PoV

Admittedly I've never fully grasped why 'Hardware-assisted virtual machine' yields 'Low performance, because of the overheads at the hardware level' in comparison to PV, it really sounds odd that hardware assistance doesn't reduce the virtualization efforts and improve performance in turn - anyway, this has been a given so far, however, it seems to yield conflicting goals now between (potential) disk and networking performance gains (maybe CPU as well), see e.g. the following FAQs (it's a mystery to me, why AWS has chosen to hide the perfectly usable/useful per FAQ permalinks in their recent redesign, alas):

• How many IOPS can hi1.4xlarge instances deliver?

Using Linux PV AMIs, High I/O instances can deliver more than 120,000 4K random read IOPS and 10,000-85,000 4K random write IOPS (depending on active LBA span) to applications across 2 * 1 TiB data volumes. For HVM and Windows AMIs, performance will be around 90,000 4K random read IOPS and 9,000-75,000 4K random write IOPS.

• How can I enable Enhanced Networking on supported instances?

Specific instance types, e.g. C3 and I2, support Enhanced Networking. In order to enable this feature, you must launch an HVM AMI with the appropriate SR-IOV driver. Amazon HVM Linux AMI includes the SR-IOV driver by default. For AMIs that do not contain the SR-IOV driver by default, you will need to download and install the appropriate driver. You can use Linux or Windows instructions to enable Enhanced Networking in AMIs that do not include the SR-IOV driver by default. Enhanced Networking is only supported in Amazon VPC.

---

:question: I'm at a loss drawing definite conclusions from this - from a pragmatic PoV (given #268 is pending anyway) I suggest we introduce an AMI mapping and assign HVM only to those instance types strictly requiring it?

[sopel]

:information_source: The preceding commit still lacks the PV/HVM AMI mapping, which I'll do next, just to avoid duplicate work ...

[mrdavidlaing]

@sopel - for the purposes of our Logsearch ES nodes we currently need to run with 60GB of RAM or we experience JVM heap problems. We don't have the metrics to tell whether faster disks, networking or CPUs make much difference; if anything, its minor.

Thus, we can switch to m2.4xlarge rather than i2.2xlarge nodes; which would allow us to sidestep the need for a PV/HVM AMI mapping

[sopel]

Well, I'm pretty much done now - at least this produces a reusable template fragment, so we are free to choose and experiment from now on ;)

[sopel]

Okay, I've fixed/added the AMI mapping depending on instance virtualization type.

:information_source: this implies an update to the Ubuntu 12.04 LTS AMI release 20140227 across the board as per the Amazon EC2 AMI Locator, i.e. I've also updated the AMI IDs for the existing PV AMIs (shouldn't make a difference except for less security updates required on instance boot, hence faster startup ideally).