First I'll note that the DRBD based HA is no longer supported, and has been removed as of Chef Server 13. Even if you are running older versions, I'd still discourage using it. DRBD/Keepalived works well when you have two servers in the same rack, with multiple ethernet interfaces tied together with crossover cables; e.g. the datacenter of 2010. It doesn't work well in a modern datacenter with virtualized hosts and more complex network structures. In particular, latency is not your friend with keepalived, and the HA solution probably provides lower actual uptime and availability.
Tiered with multiple front ends is the preferred route to scale a Chef Server, and provides a little bit of redundancy, with the caveat that the backend data store is the point of failure. It's important to keep the latency between the frontends and the backend low to maximize throughput; deploying it across data centers is not recommended. Add a good backup strategy for disaster recovery, and that should work for about 95% of the use cases.
If you need a HA solution (as opposed to disaster recovery), the modern approaches are:
BYoDB (Bring Your Own DB), possibly using a cloud provided Postgres and Elasticsearch service, or using your own and managing the availability issues yourself.
Chef Backend, which sets up a HA cluster for Postgres and Elasticsearch.
Chef Automate cluster (currently available if you have a support relationship with Chef)
These come with various operational costs and potential provider dependencies, and I'd recommend careful thought before choosing one of those. Once you go beyond BYoDB on a cloud provider, the higher availability comes with the need to be more attentive operationally.