The Basics of Workstation Provisioning
Let's start with an analogy to understand how workstations are provisioned within the data center. Imagine that the available workstations are seats on an airplane. As we've all experienced, the seats for any flight will be oversold to account for people that don't show up. But when everyone does show up some passengers get bumped. This is especially true in economy or coach. The "on-demand" workstations that are typically deployed fall in to this class, and you pay for the hours for which they are actively used.
But hey! What about all those empty seats up front? That's where we can start to look to preserve our business continuity.
The next tier up from the "on-demand" workstations are the "reserved on-demand." This is akin to the business select airfare. With these workstations you're paying a higher premium to reserve a workstation for a scheduled time period. It's still an on-demand model and does not guarantee availability, but it does give you a better chance of making your flight.
The next tier up is the first class ticket: a reserved instance. This will guarantee that your workstation is available whenever you want it because you are paying for it 24/7. Although you have the peace of mind that the workstation is available it comes at a very steep price.
Determining which instance type is right for you will be dependent on your budget and workflow needs. But if you are ready to move forward with changing your instance type you can find more information here:
- Work with Capacity Reservations - Amazon Elastic Compute Cloud
- Consuming and managing reservations (Google Cloud Platform)
BeBop's Solutions
We've implemented a few solutions to help mitigate these issues including:
Zone Deployment - We try to distribute your workstations into different "Availability Zones" within the data center. You may sometimes see that some workstations in your deployment will launch while others will give capacity errors. If this is the case try using one of the available workstations that are launching.
Best Practices - Being an agile creative
Auto Retry - We engineered an automatic retry into the desktop client so that when a capacity error is detected it will give you the option to keep trying to launch the workstation for a set amount of time.
Workflow Adaptations
Based on your workflow there are other options available to help offset capacity limitations:
BeBop Scheduler - allows you to schedule a workstation to start at a particular time. The workstation must be assigned within 15 minutes of startup. Create a ticket to request a scheduled workstation start.
Grab a workstation before typical hours - we've found that if you consistently see workstations unavailable at, for example, 9am PST, then you may have more success launching the workstation at 8:45am PST.
Updated Instance types where available - if you are on older workstations (such as a g3dn or a g4dn) you may be able to upgrade to the newer workstation models. As new models become available there will be fewer of the older models available in the data center as the CSP upgrades.
Less Powerful Instances - sometimes we can get away with less powerful instances to get around capacity issues. For example if you are using a g4dn.4xl you can deploy a g4dn.2xl that may have more availability. You are sacrificing some of the compute power and ram but the availability will let you deliver still.
Ghost Region - 2nd Pod deployed in another region - In some cases you could deploy a "ghost region." This would be a deployment in a different data center and region where there may be more availability. For instance the west and east coast data centers may have more use so you could deploy in central. The same Flex storage that you had in your initial deployment can be mounted in your ghost region.