Stephen, I think this is only possible if you deployed CF unto multiple
DCs. Same configuration, multiple DNSs


On Mon, Mar 14, 2016 at 3:55 AM, Stephen Byers <smbyers(a)gmail.com> wrote:

Agree. But the haproxy fronts the router so any client that is pinned to
the haproxy that is taken down will not make it to the router until its DNS
ttl is reached and it resolves to the other haproxy ip and even that may
not happen if this is a DNS round robin configuration.

I could be missing something?

On Sun, Mar 13, 2016, 8:44 PM Ben R <vagcom.ben(a)gmail.com> wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com>
wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.

Agree. But the haproxy fronts the router so any client that is pinned to
the haproxy that is taken down will not make it to the router until its DNS
ttl is reached and it resolves to the other haproxy ip and even that may
not happen if this is a DNS round robin configuration.

I could be missing something?

On Sun, Mar 13, 2016, 8:44 PM Ben R <vagcom.ben(a)gmail.com> wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com> wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.

Hi Stanley,

No physical memory is actually pre-allocated, it's simply a maximum used to
determine if the container needs to be killed when it exceeds it. However,
since your VM has some fixed amount of physical memory (e.g. 7.5G), the
operator will want to be able to make some guarantees that the VM doesn't
run a bunch of apps that consume the entire physical memory even if the
apps don't individually exceed their maximum memory limit. This is
especially important in a multi-tenant scenario.

One mechanism to deal with this is an "over-commit factor". This is what
Dan Mikusa's link was about in case you didn't read it yet. If you want
absolute guarantees that the VM will only have work scheduled on it such
that applications cannot consume more memory than what's "guaranteed" to
them by whatever their max memory limits are set to, you'll want an
overcommit factor on memory of 1. An overcommit factor of 2 means that on
a 7.5G VM, you could allocate containers whose sum total of their max
memory limits was up to 15G, and you'd be fine as long as you can trust the
containers to not consume, in total, more than 7.5G of real memory.

The DEA architecture supports setting the overcommit factors, I'm not sure
whether Diego supports this (yet).

The two concepts Deepak brings up, resource reclamation and predictive
analytics, are both pretty cool ideas. But these are not currently
supported in Cloud Foundry.

Best,
Amit

On Thu, Mar 10, 2016 at 7:54 AM, Stanley Shen <meteorping(a)gmail.com&gt; wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com> wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.

In your case, 2 HAProxys with DNS configured to point at both.

Is it possible to upgrade cf platform with 100% uptime for apps.

Let me give you an scenario of the platform:

1 haproxy
2 instances for gorouter, health manager
3 VMs for dea instances
1 instance for cloud controller ng, postgres, uaa etc.
1 for nfs server
1 for cc worker
1 for doppler
1 for logtraffic controller



My answer is no, because when haproxy is down, you can't connect to the
apps.

What is the right strategy for 100% uptime for apps?

Ben

Thanks everyone. What I understood from Amit's response is that I can
parallelize certain components. What I also understood from both Amit's and
Dieu's responses is that some components have hard dependencies, while
others only have soft ones, and some components have no dependencies at
all. My question is: how can I figure out these dependencies? Are they
listed somewhere? The cloud foundry docs do a great job of describing each
component separately, but they do not explain which should be up before
which. That is what I need in order to work an execution plan in order to
minimize update time, all the while keeping CF 100% available.

Thanks.

Regards,
Omar

Yes, it's one way but it's not flexible, and scale app need to restart the
app as well.
As I said I may have some heavy operations which will definitely need more
than 2G.

In my opinion the ideal way is that we just set a maximum value for each
process, but during the running of the process, we don't pre-allocate the
memory as we specify as the maximum in deployment.

I suggest you manually “cf scale -m 2G“ after your app has booted.
Type “cf scale --help” for more info.

Le 9 mars 2016 à 04:09, Stanley Shen <meteorping(a)gmail.com&gt; a

écrit :

Hello, all

When pushing an application to CF, we need to define its disk/memory

limitation.

The memory limitation is just the possible maximum value will be

needed in this

application, but in most time, we don't need so much memory.

For example, I have one application which needs at most 5G memory at

startup some

some specific operation, but in most time it just needs 2G.

So right now I need to specify 5G in deployment manifest, and 5G

memory is

allocated.

Take m3.large VM for example, it has 7.5G.
Right now we can only push one application on it, but ideally we

should can push more

applications, like 3 since only 2G is needed for each application.

Can the resources of a IDLE application be shared by other

applications?

It seems right now all the resources are pre-allocated when pushing

application, it

will not be released even I stopped the application.

As some of you may know, the Cloud Foundry Java Client has gone through
various levels of neglect over the past couple of years. Towards the end
of last year, my team started working on the project with the goal of
making it a piece of software that we were not only proud of, but that we
could build towards the future with. With that in mind, I’m exceedingly
pleased to announce our 2.0.0.M1 release.

We’ve taken the opportunity of this major release to reset what the
project is:


* What was a once hodgepodge of Java APIs both mapping directly onto the
REST APIs and onto higher-level abstractions is now two clearly delineated
APIs. We expose a `-client` API mapping to the REST calls and an
`-operations` API mapping to the higher-level abstractions that roughly
match the CLI.
* What once was an implementation of a subset of the Cloud Foundry APIs is
now a target of implementing every single REST call exposed by any Cloud
Foundry component (nearly 500 individual URIs across 4 components)
* What was once a co-mingled interface and Spring-based implementation is
now an airtight separation between the two allowing alternate
implementations (addressing one of the largest complaints about the
previous generation)
* Finally, we’ve chosen to make the API reactive, building on top of
Project Reactor, but interoperable with any Reactive Streams compatible
library


Obviously, the biggest change in this list is the move to a reactive API.
This decision was not take lightly. In fact our original V2 implementation
was imperative following the pattern of the V1 effort. However, after
consulting with both internal and external users, we found that many teams
were viewing “blocking” APIs as a serious issue as they implemented their
high-performance micro-service architectures.

As an example, we worked very deeply with a team right at the beginning as
they were creating a new Cloud Foundry Routing Service. Since each HTTP
request into their system went though this service, performance was a
primary concern and they were finding that the blocking bit of their
implementation (Java Client V1) was the biggest hit for them. We’ve
mitigated a lot of the performance bottle neck with what we’ve got today,
but for M2 we’re planning on removing that last blocking component
completely and moving to a full non-blocking network stack. This isn’t an
isolated use case either, we’ve been seeing a lot of this theme;
micro-service architectures require throughput that can’t be achieved
without either a non-blocking stack or “massive” horizontal scaling. Most
companies would prefer the former simply due to cost.

As a general rule you can make a reactive api blocking (just tack `.get()`
onto the end of any Reactor flow) but cannot make a blocking API
non-blocking (see the insanity we do to fake it, with non-optimal results,
on RestTemplate[1] today). So since we had a strong requirement to support
this non-blocking design we figured that going reactive-first was the most
flexible design we could choose.

If you want to get started with this new version, I’m sad to say that
we’re a bit lacking in the “on boarding experience” at the moment. We
don’t have examples or a user-guide, but the repository’s README[2] is a
good place to start. As you progress deeper into using the client, you can
probably piece something together from the Javadocs[3] and the Cloud
Foundry API[4] documentation. Finally, the best examples are found in our
integration tests[5]. Improving this experience is something we’re quite
sensitive to, so you can expect significant improvements here.

The reason that we’re laying this foundation is you. We’re already seeing
customers adopting (and contributing back to!) the project, but we’ve
really done it to accelerate the entire Cloud Foundry ecosystem. If you
need to interact with Cloud Foundry, I want you to be using the Java
Client. If you find that it’s not the best way for you to get your work
done, I want you to tell me, loudly and often. We’re also excited about
being in the vanguard of reactive APIs within the Java ecosystem. Having
recently experienced it, I’m sure that this transition will not be trivial,
but I am sure that it’ll be worthwhile.

A special thanks goes out to Scott Fredrick (Pivotal) for nursing the
project along far enough for us to take over, Benjamin Einaudi (Orange
Telecom) for his constant submissions, and of course Chris Frost (Pivotal),
Glyn Normington (Pivotal), Paul Harris (Pivotal), and Steve Powell
(Pivotal) for doing so much of the hard work.


-Ben Hale
Cloud Foundry Java Experience


[1]:
https://github.com/cloudfoundry/cf-java-client/blob/c35c20463fab0e7730bf807af9e84ac186cdb3c2/cloudfoundry-client-spring/src/main/lombok/org/cloudfoundry/spring/util/AbstractSpringOperations.java#L73-L127
[2]: https://github.com/cloudfoundry/cf-java-client
[3]: https://github.com/cloudfoundry/cf-java-client#documentation
[4]: https://apidocs.cloudfoundry.org/latest-release/
[5]:
https://github.com/cloudfoundry/cf-java-client/blob/master/integration-test/src/test/java/org/cloudfoundry/operations/RoutesTest.java#L114-L135

Hi

Given a DEA with 15GB, overcommit factor = 2, total "memory" is 30GB.
Ideally we can push up to 30 app instances per host, if each app instance
requires 1GB mem allocation.

Supposed the environment has 3 DEAs (max = 90GB) and we need to place a
total of 40GB of app instances:

1. should I kill the 3rd DEA given I still have "20GB" left and provision
the 3rd one when I am about to run low?
2. do you consider overcommit factor in your chargeback? i.e. despite you
can get up to 30GB, you charge customer the physical RAM (15). In this
case, you still charge the customer

n* box_price * (percentage of mem consumption / total physical
memory) = 3 * box_price * (40/45) ?

3. would I actually see "unavailable stager" error even with overcommit,
for a 40/90 deployment?

Thanks.... I hope these questions make sense.

John