The Sencha Open Source FAQ covers this use case.
There are 2 important points:
First, both the front end and backend source are likely derived works for the GPL as in this example from the FAQ:
Example
For example: let’s take a mortgage processing software program. Let’s say that the application has a front-end (that generates web pages linked to Ext JS JavaScript) that communicates over JSON/HTTP with a backend service. This backend service contains approval and validation logic for this application alone. Even if only the front-end uses Ext JS code, you should consider that the combination of front and back ends constitutes the application, and the source code for both back and front end would need to be provided to the application’s end users under GPLv3
Second, since ExtJS is run on the client they consider using the web app Conveyance:
Conveyance vs. Propagation
Since Ext JS, Sencha GXT and Sencha Touch are software programs that can run within the browser while disconnected from the network or the rest of a server program; when a Sencha based interface is embedded in a web-page served to a user who does not have an employee relationship with the original licensed entity, we consider that “conveyance” rather than simple web page “propagation” as defined by the GPL v3 has occurred, and the source code of the whole application must be provided to the user.
So you will need to make the source available to the users of the application. (Much like the AGPL.)
It is clear to me from reading their FAQ that if you intend to use ExtJS in a commercial app they want you to buy a commercial license.
It sounds like what you are really looking for is not so much High Availability as you would need Continuous Availability.
Essentially your plan will work but you seem to have noticed that the major flaw in your setup is that database schema changes in a release could result in either downtime or failure of still available node to operate correctly. Continuous Availability approach solves this by essentially creating a number of Production environments.
Production One
This environment is your current live version of the software being utilized by users. It has its own web servers, application servers, and database servers and tablespace. It operates independently of any other environment. The Load Balancer which owns the domain resolution endpoint for these services is currently pointing to these web servers.
Production Two
This is basically release staging environment that is identical to Production One. You can perform your release upgrades here and do your sanity tests before your go live event. This also affords you to safely perform your database changes on this environment. The Load Balancer does not point to this environment currently.
Production DR
This is another duplicate at a separate data center that is located in a different region of the world. This allows you to fail over in the event of catastrophic event by doing a DNS switch at the Load Balancer.
Go Live
This event is essentially updating the DNS record to cycle to Production Two from Production One or vice-versa. This takes a while to propagate throughout the DNS servers of the world so you leave both environments running for a while. Some users MAY be working in existing sessions on the old version of your software. Most users will be establishing new sessions on the upgraded version of your software.
Data Migration
The only drawback here is that not all data during that window is available to all users at that time. There is clearly important user data in the previous version database that now needs to be migrated safely to the new database schema. This can be accomplished with a well tested data export and migration script or batch job or similar ETL process.
Conclusion
Once you have fully completed your release event, Production Two is now your primary and you begin working on installing the next release to Production One for the next deployment cycle.
Drawbacks
This is a complex environment setup and it requires a large amount of system resources, often times two to three times the system resources to do successfully. Operating this way can be expensive, especially if you have very large heavy use systems.
Best Answer
You are going to want to version you ext file when you deploy. So instead of having:
You can have:
It would have a cache header that never expires and when you update to another version the name will have changed and it will force the browser to load the new file.
When you upgrade your to Ext 4.2 for example it would be :
Here is a really good write up on deployment level web devlopment. http://developer.yahoo.com/performance/rules.html Make sure to check out the "Add an Expires or a Cache-Control Header" section which talks about versioning. Versioning should also be done with your component/application level scripts as well.
This is a shameless plug but you can check out the source of my website http://www.coffeedig.com/coffee/ which is a django application written in Ext to see the versioning in action.