cb_post_boot error
18 views
Skip to first unread message
Yuna
Aug 8, 2016, 6:09:07 PM8/8/16
to cbtool-users
Michael R. Hines
Aug 8, 2016, 6:54:11 PM8/8/16
to Yuna, cbtool-users
These are common problems with new users: Security rules won't help
you here because the tool is "auto-detecting" which network to use
to reach the orchestrator: The 172.x.x.x internal network in this
case.
While the orchestrator is using the public IP address to reach the VMs in the cloud, the VMs are still using the private address in reverse to connect back to the orchestrator node.
So, you have three choices:
1) Make all traffic use the public network (Easiest, but most expensive, not recommended when the applications themselves begin benchmark traffic)
2) Make all traffic use the private network (Also easy, but requires using the same Region/Datacenter for both the VMs and the orchestrator, which is OK for the cbtool, but not OK for SPEC. Also means that you cannot use your laptop if it does not have a public IP address or is not in the same L3 network). This is the preferred method for clouds like OpenStack because everything is usually internal to whichever company is using the tool.
3) Use VPN support and ignore the networks entirely. (Most difficult, but most flexible. I use this method with DigitalOcean, as it provides the best of both worlds, but is the most complex to setup but allows the orchestrator to be anywhere in the world.)
Either way, the solution requires you to understand your networking environment very carefully and decide what network you want to use and the limitations associated with any of those choices.
Do you have a preference?
While the orchestrator is using the public IP address to reach the VMs in the cloud, the VMs are still using the private address in reverse to connect back to the orchestrator node.
So, you have three choices:
1) Make all traffic use the public network (Easiest, but most expensive, not recommended when the applications themselves begin benchmark traffic)
2) Make all traffic use the private network (Also easy, but requires using the same Region/Datacenter for both the VMs and the orchestrator, which is OK for the cbtool, but not OK for SPEC. Also means that you cannot use your laptop if it does not have a public IP address or is not in the same L3 network). This is the preferred method for clouds like OpenStack because everything is usually internal to whichever company is using the tool.
3) Use VPN support and ignore the networks entirely. (Most difficult, but most flexible. I use this method with DigitalOcean, as it provides the best of both worlds, but is the most complex to setup but allows the orchestrator to be anywhere in the world.)
Either way, the solution requires you to understand your networking environment very carefully and decide what network you want to use and the limitations associated with any of those choices.
Do you have a preference?
/* * Michael R. Hines * Platform Engineer, DigitalOcean. */
Yuna
Aug 8, 2016, 6:59:06 PM8/8/16
to cbtool-users, jo...@college.harvard.edu
Hello Michael,
I prefer option 1. Is this just a matter of
1. opening all ports in the security group
2. changing the NETNAME in the cbtool config file to "public"?
Michael R. Hines
Aug 8, 2016, 7:00:47 PM8/8/16
to Yuna, cbtool-users
Yes, that's correct.
But, keep in mind that, for example, with this option ALL inter-VM traffic, such as mapreduce or cassandra or whatever will go through the public network along with any costs associated with using that network by your cloud provider.
But, keep in mind that, for example, with this option ALL inter-VM traffic, such as mapreduce or cassandra or whatever will go through the public network along with any costs associated with using that network by your cloud provider.
/* * Michael R. Hines * Platform Engineer, DigitalOcean. */
Reply all
Reply to author
Forward
0 new messages