Here in Kansas City, we’re on the very edge of the eclipse path, and it was a beautiful night for a balloon flight too. (KOJC 210053Z 34006KT 10SM CLR 22/09 A3013 RMK AO2 SLP196 T02170094). As I was out looking at the eclipse, along comes Jason Jones of Old World Balloonery with a load of passengers, and I got a balloonar eclipse as a bonus.
My crappy phone camera gave me neat lens flare showing the eclipse in progress next to the balloon:
Amazon’s instance-store images are convenient, but ephemeral in nature. Once you shut them down, they’re history. If you want persistence of data, you want to use an EBS instance that can be stopped and started at will without losing your info. Here’s the process I went through to convert a Wowza image to EBS for a client to use with a reserved instance. I’m going to assume no configuration changes for Wowza Media Server, as the default startup package is fairly full-featured. This process works for any other instance-store AMI, just ignore the Wowza bits if that’s your situation.
Boot up a 64-bit Wowza lickey instance. I was working in us-east-1, so I used ami-e6e4418f, which was the latest as of this blog post.
Once it’s booted up, log in.
Elevate yourself to root. You deserve it:
sudo su -
Stop the Wowza service:
service WowzaMediaServer stop
delete the Server.guid file. This will cause new instances to regenerate their GUID.
rm /usr/local/WowzaMediaServer/conf/Server.guid
Go into the AWS management console and create a blank EBS volume in the same zone as your instance.
Attach that volume to your instance (I’m going to assume /dev/sdf here)
Create a filesystem on it (note: while the console refers to it as /dev/sdf, Amazon Linux uses the Xen virtual disk notation /dev/xvdf):
mkfs.ext4 /dev/xvdf
Create a mount point for it, and mount the volume:
mkdir /mnt/ebs mount /dev/xvdf /mnt/ebs
Sync the root and dev filesystems to the EBS disk:
rsync -avHx / /mnt/ebs rsync -avHx /dev /mnt/ebs
Label the disk:
tune2fs -L '/' /dev/xvdf
Flush all writes and unmount the disk:
sync;sync;sync;sync && umount /mnt/ebs
Using the web console, create a snapshot of the EBS volume. Make a note of the snapshot ID.
Still in the web console, go to the instances and make a note of the kernel ID your instance is using. This will be aki-something. In this case, it was aki-88aa75e1.
For the next step, you’ll need an EC2 X.509 certificate and private key. You get these through the web console’s “Security Credentials” area. This is NOT the private key you use to SSH into an instance. You can have as many as you want, just keep track of the private key because Amazon doesn’t keep it for you. If you lose it, it’s gone for good. Download both the private key and certificate. You can either upload them to the instance or open them in a text editor and copy the text, and paste it into a file. Best place to do this is in /root. Once you have the files, set some environment variables to make it easy:
export EC2_CERT=`pwd`/cert-*.pem export EC2_PRIVATE_KEY=`pwd`/pk-*.pem
once this is done, you’ll need to register the snapshot as an AMI. It’s important here to specify the root device name as well as map out the ephemeral storage as Wowza uses those for content and logs. Ephemeral storage will persist through a reboot, but not a termination. If you have data that needs to persist through termination, use an additional EBS volume.
ec2-register --snapshot [snapshot ID] --description "Descriptive Text" --name "Unique-Name" --kernel [kernel ID] --block-device-mapping /dev/sdb=ephemeral0 --block-device-mapping /dev/sdc=ephemeral1 --block-device-mapping /dev/sdd=ephemeral2 --block-device-mapping /dev/sde=ephemeral3 --architecture x86_64 --root-device-name /dev/sda1
Once it’s registered, you should be able to boot it up and customize to your heart’s content. Once you have a configuration you like, right-click on the instance in the AWS web console and select “Create Image (EBS AMI)” to save to a new AMI.
Note: As of right now, I don’t think startup packages are working with the EBS AMI. I don’t know if they’re supposed to or not.
I posted recently about using Amazon EC2’s cluster compute instances for big streaming projects. That post got me a call from a client in Texas who was planning to stream a big tennis tournament in Dallas and needed a server backend that could handle it, without going through the hassle and expense of setting up a CDN account for a single event. Of course, since everything is bigger in Texas, they wanted to stream to a large audience. They also wanted to be able to send a single high-definition stream for each of the two tournament courts, and then transcode down to a few different bandwidth-friendly bitrates. This called for not only big network horsepower, but big CPU horsepower as well.
I fired up the superquad (cc1.4xlarge), installed Wowza and the subscription license on it (Wowza pre-built AMIs do not exist for this instance type), and tuned it. I then created the transcoder profiles to create a 480p, 360p, 240p, and 160p stream, and we tested. Note that when installing Wowza yourself on an EC2 image, you don’t have access to the EC2-specific variables and classes out of the box. You’ll need to add the EC2 jar file that can be found on one of Amazon’s prebuilt AMIs. In this case, that wasn’t a factor, as I simply hardcoded the server’s public DNS name into any place that needed it.
Once the tournament started, we were seeing big audience numbers, with bitrates on the box well in excess of 1Gbps. On day two, audiences started complaining about spotty stream performance, and some were running 15 minutes behind live.
After jumping into the logs, it became apparent that this 8-core/16-thread monster was starved for CPU resources! Wowza recommends that a transcoder system not exceed 50-55% CPU. We then reduced the number of transcode streams to two (480p and 360p). In the process, I discovered that a misformatted search/replace had altered the configuration to transcode all the streams to 1280×720, at extremely low bitrates. No wonder the poor thing was dying. Once we got everything fixed, a full audience with both courts going was clocking in around 40% CPU. At no time in the process did Java heap memory exceed 3GB (in the tuning, I allowed it up to 8GB, the max recommended by Wowza). Wowza seems to be exceedingly efficient with its memory usage. If you need to run heavier transcoding loads, you may want to look at what I call the “super-duper-octopus” (cc1.8xlarge), which is about double what this one is.
CPU Usage - Note 2/7 when we were having trouble
Early Thursday, I checked the AWS usage stats for the month, and my jaw dropped. In three days of streaming, we’d clocked over five TERABYTES of data transfer. I expect I’ll bump into the next bandwidth tier (or come very close) by the end of the week. That’s what happens when you average around 1Gbps for the better part of 12 hours a day!
Network Usage (Bytes/Minute.. What the heck, Amazon?)
As for server usage, this instance type runs about the price of two extra-large instances (each capable of about 450Mbps), and doesn’t even break a sweat at those transfer rates. Had I parked this service on a VPS at another hosting provider, I would have blown through the monthly data cap by mid-Tuesday, and likely not had access to a 10GB pipe on the server. Meanwhile, when you start cranking terabytes of data, that cost per gigabyte is a major factor. When you crank out 10TB of data, every penny per gigabyte adds $100 to the bandwidth tab.
Although a large portion of the audience for this event was in Europe (at one point, 60% of the audience was coming from Lithuania!), the cluster instances are currently only available in the us-east (Virginia) region. If performance for European users had gotten problematic, I could have set up a repeater in Amazon’s datacenter in Ireland. As it was, there were no complaints.
So that’s how a superquad works for large streaming events. If you want some help setting one up, or just want to rent mine for your event, drop me a line.
I’m currently working on setting up Wowza on an EC2 “Cluster Compute Quadruple Extra Large” instance (or as I’ve heard it called, the “super-duper-quadruple”, which sounds like something I’d get at Five Guys). There’s no pre-built AMI for this one, so you have to use a stock Linux image (I use the standard Amazon one) and install Wowza with a subscription license, and do the tuning yourself. But the payoff is this: for $1.30 an hour, you get a streaming server capable of delivering 10Gbps of data. On a 750Kbps stream, that’s over 13,000 concurrent clients. This for about the same cost as nine or ten m1.small instances which can deliver an aggregate of about 1.5Gbps. On a reserved instance, you can get this down to just under 75 cents an hour.
In addition to Ludicrous Speed on the network I/O, this instance comes with 8 multithreaded Xeon 5570 cores (at 2.97GHz), 23 GB of RAM, and 1.7TB of local storage. (a quick speed test downloaded a half-gigabyte file in about four seconds, limited by the gigabit interface at the remote server). This is roughly equivalent to a moderately configured Dell R710. There’s also a GPU-enabled version of this that adds a pair of nVidia Tesla GPU cores.
If that’s not enough, you can go bigger, with 16 cores, 60GB of memory, and 3.5TB, Recently, someone clustered just over a thousand of these instances into the 42nd largest supercomputer in the world.
As of right now, these monster instances are only available in the us-east-1 zone.
Here’s an easy way to upload directly to S3 from an HTML form. No Java, no Flash. Thanks to @RaamDev for his handy little bit of code for doing HMAC signatures. Based on the documentation from Amazon. Makes use of the AWS SDK for PHP to list the buckets.
Screen shots:
Bucket Selection
File Selection
File Selected
Upload Success
Wowza has just updated its repository of startup packages to include pacakges specific to version 3. Get them here:
http://wowzamediasystems.s3.amazonaws.com/packagelist.html
Here’s the code for gathering Wowza Stats from a single server. This assumes that you’ve enabled the stats on Wowza (serverinfo, connectioncounts in VHost.xml HTTPProviders), with authentication turned off). You’ll also get better detailed stats if you use Andrew Kennedy’s CasterStats module for the serverinfo.
Continuing on the rack theme mentioned yesterday, I got to wondering about a stream monitor that could be switched to any of a number of live streams, without reloading the page. Fortunately, JW Player makes this easy. I threw together a player embedded inside some CSS and then added a button panel. Each button is a DIV with an onclick() action that calls jwplayer().load(). While it’s well known that you can use this to switch files simply by passing the filename to the file flashvar, we need to also pass the streamer value. Fortunately, the load() method has the ability to pass on not only files as a string value, but also objects, which are nothing more than an array of flashvars (it can also take playlist items, but that’s beyond the scope of this post). So, all you need to do in order to switch streams with JW Player is call the following JavaScript method:
jwplayer().load({file: 'streamname', streamer: 'rtmp://w.streampunk.tv/live'})
The result I got was this:
Clicking on each of the buttons in the bar below the screen will switch the stream. A live example can be found here. If you want to see what else the JWPlayer API can do, head on over to the API docs. FlowPlayer appears to have something similar in the clip.update() method (flowplayer API documentation), but I haven’t tested it.
Page code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>JW Player Switching</title>
<style type="text/css">
body { background-color: #fff; padding: 0 20px; color:#000; font: 13px/18px Arial, sans-serif; }
a { color: #360; }
h3 { padding-top: 20px; }
ol { margin:5px 0 15px 16px; padding:0; list-style-type:square; }
</style>
</head>
<body>
<!-- START OF THE PLAYER EMBEDDING TO COPY-PASTE -->
<div class="rack" style="width: 600px;">
<div class="rackmonitor" style="width: 600px; height: 323px; background-image: url('rackmonitor.png'); position: relative">
<div class="screen" style="width: 455px; height: 275px; position: absolute; left: 60px; top: 28px;">
<div id="mediaplayer">Player...</div>
<script type="text/javascript" src="/jwplayer/jwplayer.js"></script>
<script type="text/javascript">
jwplayer("mediaplayer").setup({
flashplayer: "/jwplayer/player.swf",
height: "275",
width: "455",
file: "commons.stream",
streamer: "rtmp://w.streampunk.tv/live",
autostart: true,
controlbar: 'none',
mute: true
});
</script>
</div>
</div>
</div>
<div class="panel"
style="width: 600px;
height: 57px;
background-image: url('blankPanel.png');
position: relative
">
<div class="button1"
style="width: 75px;
height: 20px;
position: absolute;
left: 50px;
top: 20px;
border-radius: 10px;
background-color: #009900;
color: #cccccc;
border: 1px solid black;
text-align: center;"
onclick="jwplayer().load({file: 'playlist-high', streamer: 'rtmp://wms.rezonline.org/redirect'})
">
RezOnline
</div>
<div class="button2"
style="width: 75px;
height: 20px;
position: absolute;
left: 150px;
top: 20px; border-radius: 10px;
background-color: #009900;
color: #cccccc;
border: 1px solid black;text-align: center;"
onclick="jwplayer().load({file: 'commons.stream', streamer: 'rtmp://w.streampunk.tv/live'})
">
Commons
</div>
<div class="button3"
style="width: 75px;
height: 20px;
position: absolute;
left: 250px;
top: 20px; border-radius: 10px;
background-color: #990000;
color: #cccccc;
border: 1px solid black;text-align: center;"
onclick="jwplayer().load({file: 'streamclass', streamer: 'rtmp://w.streampunk.tv/live'})
">
StreamClass
</div>
<div class="button4"
style="width: 75px;
height: 20px;
position: absolute;
left: 350px;
top: 20px; border-radius: 10px;
background-color: #990000;
color: #cccccc;
border: 1px solid black;text-align: center;"
onclick="jwplayer().load({file: 'aircam.stream', streamer: 'rtmp://w.streampunk.tv/live'})
">
AirCam
</div>
</div>
</body>
</html>
I’ve been experimenting with ways to generate load graphs for Wowza. The best way for doing bar graphs on a webpage is to go all crazy with CSS. It’s really well suited to doing this. Here’s a PHP script that will query a Wowza origin server for its repeaters, and then polls the repeaters for their load stats. This also provides buttons for launching/terminating repeaters, and visually representing them as a rack full of servers:
I’ve posted a couple of diagrams of Wowza’s architecture relating to repeaters and load balancing.
There’s also some additional information in the Wowza Media Server 3 Overview.