После долгих уговоров и построения кейса моя группа получила бюджет, чтобы купить 4 узла и запустить кластер cassandra. На каждой машине есть диски 3x1Tb, поэтому мне интересно, разумно ли вместо этого пропустить одностороннее резервирование и зеркалировать диски с данными.
Будет создана резервная копия данных, так что это не проблема.
Похоже, вероятность потерять машину в такой небольшой группе очень мала.
Это разумно, или мне не хватает более серьезной проблемы / фактора?
Это действительно зависит от того, для чего вы используете кассандру. Используете ли вы его для доступа к вашим данным, разделения ваших данных или того и другого? Судя по всему, вы используете его больше для разделения ваших данных, чтобы вы могли масштабировать их.
Одна из причин, по которой вы хотите реплицировать свои данные в cassandra, - это доступность. Например, если у вас есть кластер из 4 узлов с коэффициентом репликации 3, вы можете пережить потерю одного узла без необходимости какого-либо обслуживания (с уровнем согласованности кворума, 2 узла с уровнем согласованности «один»). С другой стороны, каждый из ваших узлов будет содержать 75% данных в кластере, чего, вероятно, вы надеялись избежать. Вот почему я бы попытался попросить еще один или два сервера, хотя, возможно, он вам не понадобится сразу, и вы можете добавить больше серверов по мере увеличения потребностей в данных.
Хотя вы упомянули, что потеря машины маловероятна, работа с коэффициентом репликации 1, на мой взгляд, вызывает проблемы. Вы можете никогда не столкнуться с проблемами, но когда вы это сделаете, это не будет весело. Если бы вы использовали 1 гигантский сервер для обслуживания своей базы данных, маловероятно, что он выйдет из строя, чем 1 из 4 отдельных серверов, верно?
Есть и другие причины, которые могут привести к сбою или перерыву в работе узла cassandra (сбои ОС, сборка мусора, сетевые проблемы и т. Д.).
Когда вы начинаете использовать распределенную базу данных, отказоустойчивость должна стать Больше вызывает беспокойство, чем при использовании традиционной настройки единой базы данных, и cassandra фокусируется на этом и преуспевает в этом.
У меня был прошлый опыт, когда трудно оправдать покупку оборудования и конфигурацию среды с руководством. Лучший способ заставить их понять последствия - это обрисовать сценарий отказа и указать, является ли он приемлемым, например:
Если на одном сервере произойдет сбой оборудования, данные будут повреждены или произойдет сбой в работе Cassandra, как долго мы сможем выдерживать простои?
Если ответ «0 минут», вы захотите использовать коэффициент репликации не менее 3. Это также дает больше преимуществ. При коэффициенте репликации 3 это означает, что большее количество узлов может обслуживать отдельный запрос чтения, потенциально повышая производительность чтения.
Кроме того, зеркалирование / RAID 1 считается своего рода анти-шаблоном с Cassandra для ваших данных (хотя это неплохая идея для журналов фиксации). Было бы лучше использовать RAID 0 или несколько каталогов данных, установите коэффициент репликации на 3 и позвольте Cassandra позаботиться о избыточности за вас.