WebApp
is just a name of a .NET Core Starcounter 3.0 Web Application.*WebApp
, a Starcounter application we want to make highly available, and two other resources that WebApp
depends on: an IP Address and a Database.WebApp
's dependencies, i.e. the IP Address and Database resources, and then the application.scdata
process, thus making the database available to connect to. The scdata
process locks the transaction log on CSV, reads it and then gets ready to serve incoming requests.WebApp
resource by launching WebApp.exe
. WebApp.exe
, being a web app, binds to all local addresses, including the IP Address resource we assigned to it.WebApp.exe
crashesWebApp.exe
has terminated and restarts it. The new WebApp.exe
process connects to the Database and binds to the IP Address.scdata.exe
crashesscdata.exe
has terminated. It shuts down WebApp.exe
, as it is a dependent resource. Then the usual starting sequence occurs. scdata.exe
locks and reads the transaction log from CSV and WebApp.exe
binds to the IP Address.scdata.exe
on the new node can lock the transaction log. IP Address is also transferred.scdata
in standby modescdata
process, which can take a significant amount of time. To overcome this, we need to run our scdata
instance in a special standby mode, in which it can:scdata
running on a non-active cluster node we can't use cluster resources, as WFC ensures that all resources are online on a single node. Instead we must provide an auto-started windows service, starservice
, that administers scdata.exe
for us.starservice
startsstarservice
starts scdata
in standby mode and periodically sends requests to poll transaction logstarservice
stopsstarservice
stops scdata
starservice
terminates unexpectedlyscdata
scdata
terminates unexpectedlystarservice
detects it and stops itselfstarservice
receives a request to promote scdata
to active modestarservice
passes this request on to scdata
starservice
, i.e. starting, stopping and sending promotion requests, we use a Generic Script resource.starservice
.starservice
¹. Send activate request.scdata
from active to standby mode, so we restart the service and thus scdata
, so it restarts in standby mode. It's not a problem since the resource goes offline most likely because we're transferring the group to another node, so we have enough time to load the database on this node. Next time the cluster decides to host the group again on this node, scdata
will already be prepared.scdata
when the group moves to a new node, the cluster will start the Database script resource, which in turn ensures that scdata
is started and active. WCF will handle migration of CSV, IP Address, and WebApp
.scdata
crashes, the cluster will restart it on the same node first. And it might take time. This issue could be seen as marginal, however, as scdata
should never crash. A crashing scdata
process is in of itself a more severe problem than a slow recovery.scdata
to allow it to serve read requests in standby mode. With this feature, every cluster node will become an eventually consistent read-only replica.C:\Path\To\Db
& C:/Path/To/Db
are treated as different.*star
tool:sccreatedb
tool:starservice
on every nodestarservice
files to all nodes. These files should have the same lication on all nodes.sc.exe
tool:starservice.exe
tool itself:scripts
folder from the previously downloaded archive to all nodes. The local path should be the same on all nodes. Don't use the CSV volume as it will complicate resource upgrade and troubleshooting.WebApp
resourceWebApp
files to all nodes. The local path should be the same across nodes. Don't use CSV volume as it will complicate resource upgrade and troubleshooting.