问题标签 [cluster-computing]

我想编写一个集群感知应用程序，它将跟踪集群组的状态。

更具体的，我想追问一下群主。应用程序应该知道本地机器是否是组的所有者，并据此行事。

我可以为此调查注册表吗？如果是，在哪里？如果没有，有人知道将提供此信息的任何 win32 api 调用吗？

非常感谢，

提供

尝试使用本地系统用户，但它没有访问网络的权限。网络服务帐户可以解决问题吗？，如果不是，推荐使用什么用户？

据我所知，SQL Server 提供了 4 种技术来提高可用性。

我认为这些是主要的使用场景，总而言之：-

1）复制将主要适用于在线离线数据同步场景（笔记本电脑、移动设备、远程服务器）。

2) 日志传送可用于具有手动切换的故障转移服务器，而

3) 数据库镜像是一种自动故障转移技术

4) Failover Clustering 是一种高级的数据库镜像。

我对吗 ？

谢谢。

有谁知道集群/负载平衡软件（免费或商业），一旦设置，只需要您在一个地方登录，所有硬盘驱动器都安装在一起？

例如，目前我有 1 台服务器，我通过访问 www.myurl.com/cpanel 访问它，并显示一个硬盘驱动器，我在那里上传了我所有的网站文件。

如果我有 100 台 linux 或 windows 服务器使用负载平衡器连接在一起并希望将它们作为一个集群运行，是否有软件可以让我直接访问 www.myurl.com/cpanel，一旦我登录，我将不会看到超过 1 个硬盘驱动器，但我会看到所有硬盘驱动器的总空间，所以我可以只上传 1 个文件，它会自动上传到所有硬盘驱动器？

如果目前没有这样的软件，你认为有可能编写这样的程序吗？或者有没有一个软件，你把文件放在你的网站上，网站访问者下载它，一旦他们运行文件并连接到互联网，他们的互联网连接就成为你的网络服务器的一部分，所以当人们访问你的网站时，一些数据和 cpu 使用情况来自您的 Web 服务器，而一些数据和 cpu 使用情况来自下载文件的用户？

我需要将大量数据（数百万个文件，TB 级数据）迁移到 SQL 集群。迁移过程被划分为每周迁移，每周有数百个新用户（即请求生成器）。

到目前为止，一切进展顺利，但最近我发现 SQL 集群开始表现得很奇怪。CPU 使用率稳定在 20% 左右，但 SQL 进程不断分配新内存，直到没有剩余内存（约 12GB）。发生这种情况时，该进程会“转储”所有内存并重新开始向 12GB 攀升。在此转储期间，通常会出现服务器无响应并最终超时的情况，而这在这周的迁移中是不可能发生的。

这种分配和转储行为是否常见于 SQL 集群？是否可以对其进行配置以使这种情况永远不会发生，或者至少不会使整个数据库拥塞？有人有大型移民工作的经验吗？

查看事件日志时，我发现在超时之前有一些 WMI 警告。我们正在使用 System Center Operations Manager 2007 来忽略系统，这可以解释这种行为吗？

感谢您的帮助！

通过上万个请求/秒，我希望看到 60,000 -> +90,000 个请求/秒。

我的设置包括以下内容：

用户 ---> Web 应用程序 --> 消息队列 --> 解析器 --> 数据库？

我应该提到，解析器目前可以使用 COPY 解析/填充大约 18750 条记录/秒，因此在我们开始添加更多解析器之前，我们在这方面受到限制——这对我来说现在不是一个大问题。

我有一个系统，需要能够尽可能快地批量上传尽可能多的记录。这个相同的系统（或者它可以根据您的处理方式而有所不同）应该能够响应分析类型的查询，例如：

.....10-15 千次（每个用户），因为它们被锁定到另一个表。不用说，我们现在将这些结果分页为 10/页。

我查看了以下内容：（假设这些都在同一台服务器上）

• mysql (reg. run of the mill rdbms)——能够进入 15-20,000 个请求/秒的范围；在当前条件下，如果我们尝试扩展它，我们每次需要扩展时都需要一个单独的主机/数据库——这是不可行的

• couchdb（面向文档的数据库）——没有打破 700 个请求/秒；我真的希望这能拯救我们的屁股——不是机会！

• vertica（面向列的数据库）——达到 60000 个请求/秒，封闭源代码，非常昂贵；这仍然是一个选择，但我个人根本不喜欢它

• tokyocabinet（基于哈希的数据库）——目前的重量为 45,000 次插入/秒和 66,000 次选择/秒；昨天当我写这篇文章时，我使用了一个基于 FFI 的适配器，它的性能大约为 5555 个请求/秒；这是迄今为止我见过的最快最棒的数据库！

• 兵马俑——（vm集群）目前正在与jmaglev一起评估它（不能等到maglev本身出来）——这是最慢的！

也许我只是错误地解决了这个问题，但我总是听说 RDBMS 非常慢 - 那么我听说过的这些超快速系统在哪里？

测试条件::

只是让人们知道我在我的开发盒上的规格是：

Mysql mysql.cnf 编辑为：

更新::

事实证明，terracotta 可能在我们的应用程序结构中占有一席之地，但它不会很快替换我们的数据库，因为它的速度很糟糕，而且它的堆利用率很糟糕。

另一方面，我很高兴看到 tokyocabinet 的 NON-FFI ruby​​ 库（意思是 tyrant/cabinet）超级快，现在它是第一名。

如今，使用商用硬件实现 TB 级分布式内存缓存会是最具成本效益的方式吗？什么是商品硬件？

我有两个集群在一起并复制会话的 Oracle 应用服务器 (OAS) 实例。每当我通过终止进程来终止其中一个实例时，另一个实例就会启动并包含该会话。一切都按预期工作。如果我正常关闭 OAS 的一个实例（使用 opmn stopall），则会触发 HttpSessionDestroyedEvent 事件并删除信息，从而导致应用程序无法正常故障转移。这是我第一次使用集群环境，我很好奇这是否常见。我知道并期望在服务器实例停止时在非集群环境中触发 HttpSessionDestroyedEvent 事件，但这里似乎不正确。如何在一台服务器上执行任何类型的维护？我正在使用 Spring Framework，这是 HttpSessionDestroyedEvent 事件的来源。

我正计划使用无共享架构和多版本并发控制来制作分布式数据库系统。冗余将通过异步复制实现（只要系统中的数据保持一致，它就可以在发生故障时丢失一些最近的更改）。对于每个数据库条目，一个节点具有主副本（只有该节点对其具有写访问权限），此外，一个或多个节点具有条目的辅助副本以用于可伸缩性和冗余目的（辅助副本是只读的） . 当条目的主副本被更新时，它会被打上时间戳并异步发送到具有辅助副本的节点，以便最终他们将获得条目的最新版本。拥有主副本的节点可以随时更改 - 如果另一个节点需要写入该条目，它将请求主副本的当前所有者给该节点该条目的主副本的所有权，

最近我一直在思考当集群中的一个节点出现故障时该怎么办，使用什么策略进行故障转移。这里有一些问题。我希望您至少知道其中一些的可用替代品。

• 在分布式系统中进行故障转移有哪些算法？
• 分布式系统中有哪些共识算法？
• 集群中的节点应该如何判断一个节点宕机了？
• 节点应如何确定故障时哪些数据库条目在故障节点上有其主副本，以便其他节点可以恢复这些条目？
• 如何确定哪些节点具有某个条目的最新辅助副本？
• 如何决定应该将哪个节点的辅助副本提升为新的主副本？
• 本来以为down的节点突然又像什么都没发生一样怎么处理？
• 如何避免出现裂脑场景，网络暂时一分为二，双方都认为对方已经死了？

我了解多线程程序和依赖机器间通信的程序之间的区别。我的问题是我有一个很好的用“C”编写的多线程程序，它在 8 核机器上运行良好。现在有机会将此程序移植到集群以访问更多内核。是否值得努力撕掉 pthread 的东西并改造 MPI（我从未使用过），或者我们最好从头开始重新编码整个东西（或大部分）？假设我们被 C “卡住”了，所以不能选择大规模改变语言。