标签: high-availability

我一直在研究一个项目,它是一个应用程序服务器和一个对象数据库的组合,目前只在一台机器上运行.前段时间我读了一篇描述分布式关系数据库的论文,并对如何将该论文中的想法应用到我的项目中提出了一些想法,以便我可以使用共享在集群上运行它的高可用性版本- 没什么架构.

我的问题是,我没有设计分布式系统及其协议的经验 - 我没有参加大学分布式系统的高级CS课程.因此我担心能够设计一个不会导致死锁,饥饿,裂脑和其他问题的协议.

问题:在哪里可以找到有关设计分布式系统的好材料？有哪些方法可以验证分布式协议是否正常工作？欢迎提供书籍,学术文章和其他建议.

这里有一个很好的讨论,关于使用Kingsby的Jesper库模拟Cassandra中的分区问题.

我的问题是 - 在Cassandra你主要关注CAP定理的分区部分,还是一致性是你需要管理的一个因素？

同样,应该避免设计模式吗？

Redis看起来确实是一款内置复制和惊人速度的绝佳产品.经过测试后,感觉就像是2010年memcached的替代品.

但是,由于通常使用memcached时,会使用一致的散列来均匀地在池中的服务器上分布数据.如果池中的某个服务器出现故障并且无法访问,则会以透明方式处理它,只会丢失丢失的密钥并将其均匀分布到池中剩余的可用服务器上.

另一方面,Redis还内置了分片,但另一个真正有趣的功能叫做自动复制.由于这一点,在狗屎击中风扇的情况下利用从属服务器时,可以大大提高数据的可用性.

但是,我还没有找到任何好的解决方案来处理将redis服务器的状态更改为自动成为新主服务器或通过任何其他方式自动处理Redis故障转移.

怎么可以这样做？对此有什么合适的方法？

作为使用ElasticSearch作为可靠文档存储的调查的一部分,我从Java应用程序运行基本HA测试,如下所示:

我使用ElasticSearch 1.6(https://registry.hub.docker.com/_/ elasticsearch )的现成Docker镜像设置了一个最小集群,其中:

• 2个主/数据节点
• 1个客户端节点(总是有人连接到)

然后我运行一个小型加载器应用程序,每个文件插入500,000个文件,每个约1KB.

我的机器大约需要1分半钟.在此期间,我重新启动当前主节点(docker restart).

在运行结束时,Java API已经对100%的查询做出了响应,但是当我使用curl请求检查文档计数时,缺少一些文档(根据我的运行,在2到10之间)

即使索引上有明确的"_refresh"请求,我的文档计数也是一样的.

我当然主要担心的是,崩溃期间无法存储某些文档,而是API返回的正面结果(特别是因为我正在使用WriteConsistencyLevel.ALL进行测试).

我知道这张票,但不确定它是否适用于我的基本场景

• https://github.com/elastic/elasticsearch/issues/7572

我的插入操作如下:

client.prepareUpdate("test", "test", id)
      .setDoc(doc).setUpsert(doc)
      .setConsistencyLevel(WriteConsistencyLevel.ALL)
      .execute.get.isCreated == true

其余的代码可以在这里找到:https: //github.com/joune/nosql/blob/master/src/main/scala/ap.test.nosql/Loader.scala

如果您认为我做的事情明显错误,请告知.

(我知道有些人会回答说,考虑到ElasticSearch作为一个可靠的文档存储是完全错误的,但这是研究的目标,而不是我期望的那种答案)

按照Andrei Stefan的要求更新其他日志

> grep discovery.zen.minimum_master_nodes elasticsearch.yml
discovery.zen.minimum_master_nodes: 2

> curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{"transient":{"logger._root":"DEBUG"}}'
{"acknowledged":true,"persistent":{},"transient":{"logger":{"_root":"DEBUG"}}}%
> curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{"transient": {"logger.index.translog":"TRACE"}}'
{"acknowledged":true,"persistent":{},"transient":{"logger":{"index":{"translog":"TRACE"}}}}%

使用200,000个条目运行测试:

0 KO | 200000 OK
> curl -XGET 'localhost:9200/test/test/_count?preference=_primary'
{"count":199991,"_shards":{"total":5,"successful":5,"failed":0}}%  

我把日志放在这里:https://gist.github.com/ab1ed844f2038c30e63b

官方Kubernetes教程的第一部分指出,

处理生产流量的Kubernetes集群应至少具有三个节点.

但没有给出为什么三个是首选的理由.为避免裂脑情况,仅仅允许更大的可用性,或满足Kubernetes内部特定的东西,三个是否超过两个是可取的？我原以为只有多个Kubernetes集群(每个集群都有不同的主服务器)才会出现裂脑情况,而单个集群应该能够处理至少两个节点,每个节点可能都在自己的可用区中.

故障转移和灾难恢复之间有什么区别？

我正在尝试构建非常轻量级的解决方案,以便为Java应用程序实现零停机部署.为简单起见,我们认为我们有两台服务器.我的解决方案是使用:

1. 在"前端" - 一些负载均衡器(软件) - 我在这里考虑HAProxy.

2. 在"后面" - 两台服务器,都运行Tomcat和已部署的应用程序.

当我们即将部署新版本时

1. 我们使用HAProxy禁用其中一个服务器,因此只有一个服务器(让我们称之为服务器A,运行旧版本)将可用.

2. 在其他服务器上部署新版本(让我们称之为服务器B),运行生产单元测试(如果我们有它们:-)并使用HAProxy启用服务器B,同时禁用服务器A.

3. 现在我们只有一个服务器活动(服务器B,新版本).在服务器B上部署新版本,然后重新启用它.

任何建议如何改善？怎么自动化？

任何现成的解决方案或我必须最终得到我自己的自定义脚本？

谢谢!

我正在尝试设置RabbitMQ服务器集群,以使用主动/被动服务器架构获得高可用性队列.我正在遵循这些指南:

1. http://www.rabbitmq.com/clustering.html
2. http://www.rabbitmq.com/ha.html
3. http://karlgrz.com/rabbitmq-highly-available-queues-and-clustering-using-amazon-ec2/

我对高可用性的要求很简单,我有两个节点(CentOS 6.4)与RabbitMQ(v3.2)和Erlang R15B03.Node1必须是"活动的",响应所有请求,Node2必须是"被动"节点,其中包含所有队列和消息(来自Node1).

为此,我配置了以下内容:

• RabbitMQ的Node1在非集群模式下工作正常
• RabbitMQ的Node2在非集群模式下工作正常

我接下来要做的是在两个节点之间创建一个集群:将Node2加入Node1(指南1).之后,我配置了一个策略来镜像队列(指南2),复制集群中所有节点之间的所有队列和消息.这可行,我可以连接到任何节点并发布或使用消息,同时两个节点都可用.

当我有一个在Node1上创建的队列"queueA"(队列A上的主服务器),并且当Node1停止时,我无法连接到Node2中的queueA来生成或使用消息时,Node2会抛出错误说Node1不可访问(我认为queueA没有被复制到Node2,并且Node2不能被提升为queueA的master).

错误是:

{"AMQP操作被中断:AMQP关闭原因,由Peer发起,代码= 404,text = \"NOT_FOUND - vhost'app01'中持久队列'queueA'的主节点'rabbit @ node1'关闭或无法访问\ ",classId = 50,methodId = 10,cause ="}

使用的步骤顺序是:

节点1:

1. rabbitmq-server -detached
2. rabbitmqctl start_app

节点2:

3. Copy .erlang.cookie from Node1 to Node2
4. rabbitmq-server -detached

加入集群(Node2):

5. rabbitmqctl stop_app
6. rabbitmqctl join_cluster rabbit@node1
7. rabbitmqctl start_app

配置队列镜像策略:

8. rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

注意:用于队列名称的模式是""(所有队列).

当我运行'rabbitmqctl list_policies'和'rabbitmqctl cluster_status'时一切正常.

如果Node1不可用,为什么Node2无法响应？这个设置有什么问题吗？

如果我正确理解CAP定理,则可用性意味着即使节点出现故障,群集也会继续运行.

我见过很多人(http://blog.nahurst.com/tag/guide)将RDBMS列为CA,但我不明白RBDMS是如何可用的,就好像一个节点出现故障,集群必须关闭保持一致性.

我唯一可能的答案是大多数RDBMS都是单个节点,因此没有"非故障"节点.但是,这似乎是一种技术性,而不是真正的"可用性",绝对不是高可用性.

谢谢.