github.com/adityamillind98/nomad@v0.11.8/website/pages/docs/faq.mdx (about) 1 --- 2 layout: docs 3 page_title: Frequently Asked Questions 4 sidebar_title: FAQ 5 description: Frequently asked questions and answers for Nomad 6 --- 7 8 # Frequently Asked Questions 9 10 ## Q: What is Checkpoint? / Does Nomad call home? 11 12 Nomad makes use of a HashiCorp service called [Checkpoint](https://checkpoint.hashicorp.com) 13 which is used to check for updates and critical security bulletins. 14 Only anonymous information, which cannot be used to identify the user or host, is 15 sent to Checkpoint. An anonymous ID is sent which helps de-duplicate warning messages. 16 This anonymous ID can be disabled. Using the Checkpoint service is optional and can be disabled. 17 18 See [`disable_anonymous_signature`](/docs/configuration#disable_anonymous_signature) 19 and [`disable_update_check`](/docs/configuration#disable_update_check). 20 21 ## Q: Is Nomad eventually or strongly consistent? 22 23 Nomad makes use of both a [consensus protocol](/docs/internals/consensus) and 24 a [gossip protocol](/docs/internals/gossip). The consensus protocol is strongly 25 consistent, and is used for all state replication and scheduling. The gossip protocol 26 is used to manage the addresses of servers for automatic clustering and multi-region 27 federation. This means all data that is managed by Nomad is strongly consistent. 28 29 ## Q: Is Nomad's `datacenter` parameter the same as Consul's? 30 31 No. For those familiar with Consul, [Consul's notion of a 32 datacenter][consul_dc] is more equivalent to a [Nomad region][nomad_region]. 33 Nomad supports grouping nodes into multiple datacenters, which should reflect 34 nodes being colocated, while being managed by a single set of Nomad servers. 35 36 Consul on the other hand does not have this two-tier approach to servers and 37 agents and instead [relies on federation to create larger logical 38 clusters][consul_fed]. 39 40 ## Q: What is "bootstrapping" a Nomad cluster? ((#bootstrapping)) 41 42 Bootstrapping is the process when a Nomad cluster elects its first leader 43 and writes the initial cluster state to that leader's state store. Bootstrapping 44 will not occur until at least a given number of servers, defined by 45 [`bootstrap_expect`], have connected to each other. Once this process has 46 completed, the cluster is said to be bootstrapped and is ready to use. 47 48 Certain configuration options are only used to influence the creation of the 49 initial cluster state during bootstrapping and are not consulted again so long 50 as the state data remains intact. These typically are values that must be 51 consistent across server members. For example, the [`default_scheduler_config`] 52 option allows an operator to set the SchedulerConfig to non-default values 53 during this bootstrap process rather than requiring an immediate call to the API 54 once the cluster is up and running. 55 56 If the state is completely destroyed, whether intentionally or accidentally, on 57 all of the Nomad servers in the same outage, the cluster will re-bootstrap based 58 on the Nomad defaults and any configuration present that impacts the bootstrap 59 process. 60 61 [consul_dc]: https://www.consul.io/docs/agent/options.html#_datacenter 62 [consul_fed]: https://www.consul.io/docs/guides/datacenters.html 63 [nomad_region]: /docs/configuration#datacenter 64 [`bootstrap_expect`]: /docs/configuration/server#bootstrap_expect 65 [`default_scheduler_config`]: /docs/configuration/server#default_scheduler_config