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 scdatastarservice terminates unexpectedlyscdatascdata terminates unexpectedlystarservice detects it and stops itselfstarservice receives a request to promote scdata to active modestarservice passes this request on to scdatastarservice, 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.