Introduction
I really like Amazon Web Services for development purposes. It’s fast (enough), big (more than enough), and flexible (ah, just right) for my purposes. What do you do with it? Have you given any thought to treating that AWS EC2 instance (that’s an Amazon Web Services Elastic Computing Cloud virtual machine for the uninitiated) as a full-fledged server?
Splendid isolation
One approach, per the my earlier post, is to install all client software, including Microsoft Excel, on the server and just use Remote Desktop Connection (RDC) to connect to that EPM cloud instance. This is a great approach if you are the only user of the instance (like me in my development/kick the tires/play with the product till you understand it usage). But what happens when you want to collaborate with someone else or have multiple users check out the awesomeness that is your Essbase/Planning/HFM/Profitability/Close Management/Profitability/Studio/ODI/etc./etc./etc. work?
No geek is an island
Amazon Web Services (AWS) is predicated on servers, and after all the EPM software is server-based – why not treat your instance like a server and your PC like a client? While connecting as a client to your EPM instance in the cloud is slightly harder than connecting to a server down the hall, it is easier than you think and requires just a few changes to the AWS Security Group.
And of course there is a huge benefit – more than one person, e.g., your customers, be they internal or external, can connect to the EPM server. You do like to share, right?
Requirements
You must have:
- A valid AWS id
- An already created security group
- A PC with Excel 2007 or 2010 (2003 is also supported but the examples show 2007/2010’s ribbon interface)
- Already read the most-read (Google Analytics tells all) post I have ever written
- Microsoft’s Remote Desktop Connection (RDC). This client is standard in Windows; Macintosh users go here: http://www.microsoft.com/mac/remote-desktop-client)
- Time and a willingness to experiment :)
Make sure you do not have Smart View installed as its download and installation is covered below.
Understanding AWS Security Groups
Ports
Security groups are used to define the open ports between an Amazon Web Services (AWS) instance and its clients. By default all server ports are closed by Amazon’s firewall. These ports must be opened for a client to connect to the instance.
As was illustrated in the “Yeah, yeah 11.1.2.1 is here, so what?” instructions, managing the AWS Windows instance required port 3389 to be opened to allow RDC to connect.
IP addresses
AWS provides a powerful method to limit unauthorized connection to an instance – internet protocol (IP) address filtering. In essence, AWS allows you to do define which client external IP addresses will connect to a given instance. It can be the whole world, or it can be just the EPM users in a given location or company.
This external IP address is not the same as your PC’s internal address on the LAN – it is the address the outside world sees and interacts with; usually one address is shared for a given organization or location. Sophisticated AWS security is beyond the scope of this post (not to mention my abilities) but to get a taste of what is possible, investigate Amazon’s Virtual Private Cloud and the Elastic IP component of Elastic Compute Cloud for more information.
For simplicity, this document will use a 0.0.0.0 IP address, as did the 11.1.2.1 instructions. In AWS, a source IP address of 0.0.0.0 allows connectivity from and to all client IP addresses on the internet, including the ones belonging to those nasty people who do nothing but troll the ‘net looking for vulnerable servers. You do not want to use this completely open IP address range for anything other than training purposes. Figuring out your public IP address is easy; here is one site that provides this free service: http://whatismyipaddress.com/ip-lookup
One final note on wide open IP addresses -- when the authors connect to AWS, whether it be from work or home, they always use their public IP address, never 0.0.0.0.
Opening up the ports
A good test of true client/server connectivity is Smart View against Essbase. Smart View uses ports 19000 for shared connections and 13080 for Essbase private connections. If you set up your security group as described in the post-I-am-mentioning-yet-again, the only open port in your AWS security group will be Remote Desktop’s 3389.
Modifying the Security Group
You will need to expand the open ports by first logging in to AWS’s Elastic Compute Cloud (EC2) console and then clicking on the Security Groups link:
Once in the group, in this case it is called KScopeTest, click on the Inbound tab:
Adding port 19000
You will see port 3389 already open. To add port 19000, type in the port number in the Port range field and then the Add Rule button:
Adding port 13080
Do the same for the private connections on port 13080:
You can click on the Apply Rule Changes button at any time to commit the new port number; you must do so at the end of the port addition steps.
Knowing when to connect
As you know, it can be hard to determine when an AWS instance has started up after launch from an Amazon Machine Image (AMI). The AWS console instance information is limited to four states: terminated, stopped, pending, and started. Started means just what it says – the instance is started, but all that really means initially is that the server has been turned on, not that you can connect.
When an instance has not fully booted, it cannot accept connections; the only way to know if you can connect or not is to try.
Ping comes to the rescue
One way to gain some insight into whether an instance can be connected to is to see if basic networking protocols can be used, e.g, pinging the box using the ping utility. However, by default AWS instances can not be pinged because the protocol that allows ping and traceroute is disabled. Thus a further modification of the security group is required to allow ping from your client to reach the AWS instance.
To do this, click on the Create an new rule dropdown and select Custom ICMP rule:
When you select Custom ICMP rule, the Type dropdown automatically switches to All.
Click on the Add Rule button to add the ICMP ports. You must also click on the Apply Rule Changes button to commit the port changes.
Once committed, the Security Group should look like the following:
Port review
Port | Purpose |
ICMP/All | Allow ping, traceroute, etc. |
3389 | Allow Remote Desktop connection |
13080 | Smart View private connections to Essbase |
19000 | Smart View shared connections, Workspace, etc. |
We have only opened the ports required for connection: ICMP, 3389, 13080, and 19000.
As an example of port access, if your EPM instance were to support the classic Essbase Excel add-in, add port 1423 to allow connecting to Essbase and ports 32768 through 32778 to allow connections to the Essbase agent and databases.
As a general rule of firewall security, only open the ports needed for your work.
Launch that instance
The detail and rationale behind the steps required to launch an instance were covered in the post-whose-name-must-not-be-mentioned-lest-we-all-go-mad; refer to it for background. If you dare.
Which one?
For the purposes of this example, John Booth’s free and public EPM 11.1.2.1 AMI will be used. You can find out all about the AMI at http://www.metavero.com.
3…2…1…launch!
To find and then launch that AMI, enter the AMI id ami-de2bd4b7 in the filtering textbox in the AMI section of the EC2 console and click on the Refresh button.
Once it appears, right click on the AMI name and select Launch Instance. Make sure you use the Security Group KScopeTest you previously created.
Follow the Launch Instance wizard (see the below for the kinds of selections you should make) and at the Review step start the instance by clicking on the Launch button.
Two ways to see if the instance is really ready
Approach #1 – Check System Log
Right click on the instance and select “Get System Log”.
Review the log
Remember, you are firing up a Windows 2008 server. It is not going to be fast. Give yourself time to get a cup of coffee. In fact, you can likely dump the grounds, scrub the filter basket, put in a new filter, measure out the coffee grounds, put in fresh water, and hit the start button and wait for that delicious pot of Life Blood. In other words, there is likely a 10 to 15 minute wait ahead of you.
You will eventually see something like the below; you may need to check back several times. When you do see it, the log is telling you the truth – you can now connect via RDC.
Approach #2 – Ping the server
Checking the system log is all very well, but it can require multiple tests to ascertain if the instance is strated.
Instead, the familiar ping command can be used to go against the instance – when Windows has booted, the ping command will be echoed back to your client.
Get the DNS name
Once the AMI is launched, grab the public DNS name by trying to connect to the Instance. Yes, that instance will almost certainly not be ready to connect to – you are just going through the motions to get the address.
Right click on the instance name and select Connect.
The AWS console will show the DNS name. Copy that to the clipboard.
Ping from the comand line
Start up a command window, and then enter ping DNSname. In the case of the above DNS address (every launched instance will have a different one and yours will not match the above), the command would be ping ec2-184-73-120-11.compute-1.amazonaws.com
Although a successful reply from the instance is not complete proof that Windows is ready receive Remote Desktop connections, it is a good gauge that the EC2 instance and related Elastic Block Storage (EBS) drive have been created from the AMI and that the OS is in the process of booting up.
This is one of those differences between a GUI and a command line – the GUI requires you to act again and again, while the command line just keeps chugging away until it receives a reply. Which would you rather do?
Connect via Remote Desktop
Once you get a reply from your ping command or from the Get System Log menu, connecti via Remote Desktop by going back to that AWS dialog box and then clicking on the Download shortcut file link.
In Firefox, Remote Desktop will open the .rdp (a config file for RDC) file.
A scary message will ensue. Ignore it – this has nothing to do with AWS and is intead a feature of Windows 7/Remote Desktop.
Enter the password “epmtestdrive”.
Another scary message pops up – again this can be ignored by clicking on the Yes button.
When you have connected to your instance, minimize your Remote Desktop window as you will now connect from your client PC.
Connecting to an EC2 EPM image from your PC
Prove that Workspace is running
On your client PC, launch a browser instance (this example shows Internet Explorer as Workspace is optimized for that browser) and create a url to launch Workspace.
The normal Workspace url is:
http://servername:19000/workspace/index.jsp
The public DNS name of this instance is ec2-184-73-120-11.compute-1.amazonaws.com.
Incorporate the DNS name into the url as follows (remember, in your case the DNS name will be whatever Amazon assigns to the instance):
http://ec2-184-73-120-11.compute-1.amazonaws.com:19000/workspace/index.jsp
Type that url into the browser’s address bar and hit the Enter key. If all of the services are running on the AWS instance, you should see the below Workspace login screen.
Enter a username of admin and a password of epmtestdrive and you will see the familiar Workspace home page.
Download SmartView
The goal is to connect Smart View, not Workspace. Navigate to the Workspace Tools menu, select Install, and then Smart View. This will begin the download to your client PC.
NB – This guide assumes that Smart View is not installed. If it is, unistall it to follow the remaining steps.
Internet Explorer will prompt for a save location for Smart View.exe.
Install Smart View
Once saved, navigate to the same location and right click on SmartView.exe and select Run as administrator.
Vista and Windows 7’s User Account Control will ask if you really want to run this file – you do.
Click on Run and the installation process will begin.
Pick a language – in the case of this guide, that is English (United States) and click on OK. The installation process will begin.
The installation process begins…
Follow the wizard all the way through to the end.
Launch your PC’s local copy of Excel – you should see the Smart View ribbon.
Defining the Application Provider Services (APS) address
After going to the Smart View ribbon, click on the Open button and then the Shared Connections link in the Connection Manager. Smart View will surface a dialog box asking you to modify the url for Shared Services. Smart View connects to Essbase through APS – this is the address you are really providing.
In the case of this EPM instance, all services are installed on a single server.
The default url is: http://server:port/workspace/Smart ViewProviders
Using the same DNS name that was used to ping the server and to connect to Workspace, change that URL to (again, your DNS name will differ from the below):
http://ec2-184-73-120-11.compute-1.amazonaws.com:19000/workspace/Smart ViewProviders
Paste it into the Shared Connections URL dialog box in Smart View’s Options dialog box.
Smart View will then show the Connect to Data Source dialog box. Enter the same username and password of admin and epmtestdrive and then click on Connect.
Now go into Connection Manager and click on the server drop down to define an Essbase server.
Then click on the Add new server dropdown.
Paste in the public DNS name of: ec2-184-73-120-11.compute-1.amazonaws.com and click on OK.
Smart View will show you the Essbase service in your instance. Below are the sample applications that come with Essbase.
From here on out, you can connect to Essbase just as if the server was in your data center.
It’s the same Essbase you know and love, only in the cloud. It really is that easy.
When you are done
AWS instances are billed by the hour – if there is no usage, nor is it anticipated, it might be in your best interest to stop the server.
If you want to retain your work you have two choices:
1) Stop (not terminate) your server via the EC2 console. This is akin to shutting down your server. You can bring it up at any time and will incur small storage costs based on size of $0.10 per gigabyte month.
2) Create an AMI (coming soon on this blog) from the instance and Terminate the instance. Charges for AMI storage are slightly less than EC2’s EBS model, but mean that you have to launch the AMI and manage multiple AMI copies.
If this was throwaway work, simply terminate the instance. Remember, there is no going back to the data once the instance has been terminated.
DNS changes
Once you stop (or create an AMI and terminate the source instance) the instance, the public DNS name will be lost. On subsequent startup, you will need to rename Smart View’s APS server name.
One way around this is to use AWS’ Elastic IP service; find out more about it here: http://aws.amazon.com/ec2/ Elastic IP will allow you define a static IP address and AWS will map the dynamic IP address to that static one so that clients do not have to change their server names; there are further configuration steps beyond the scope of this guide – search the web for more information.
Two alternate DNS providers are:
http://www.dyndns.com/services/dns/dyndns/
Conclusion
What do you now have?
- A fully functioning Essbase server in the cloud that you, and your colleagues, can use for any purpose Essbase might fill.
- A test server that can be created in minutes for experimentation when your development server is unavailable.
- A platform for learning the features of the very latest EPM release.
- A server that can be almost instantly adjusted, whether it be the number of CPUs, the amount oF RAM, or the hard drive size.
All for mere pennies an hour.
