NameNode 的动态扩缩容一般的方式如下：1、水平扩展：对于 NameNode，可以采用主备模式部署，利用 ZooKeeper 等工具实现自动故障转移。当主 NameNode 负载过高或发生故障时，自动切换到备用 NameNode。2、优先级负载均衡：在主备模式下，可以使用负载均衡器，将请求优先发送到主 NameNod...
1、创建网络策略，限制离线任务Pod与在线业务Pod之间的直接通信。这样可以避免离线任务占用在线业务的网络带宽 。2、在物理层面，使用不同的网络接口和交换机配置，将在线业务和离线任务的网络流量隔离 。3、利用虚拟网络技术（如VLAN、VXLAN）在同一物理网络上创建多个逻辑网络，实...
在选择大数据混合部署的容器化技术路线时，完全容器化和部分容器化各有优劣，最终选择取决于具体的业务需求、现有技术栈、团队技能和长远发展规划 ，简单来说就三类：* 现代化需求强烈且具备相应技术能力的企业 ：可以选择完全容器化，使用 Spark on K8S。已有大量 Hadoop 工作负载...
实际上这个问题可以从两个部分看1 在你使用pg_resetwal 不指定时间的情况下，并启动数据库发现数据丢失，是由于 WAL日志没有正确应用到数据库中造成的，数据库是通过WAL来保证数据的一致性，那么你的WAL 没有应用对，那么必然数据丢失。但比较遗憾的是，基于操作这对于数据...
匿名用户
个人感觉，从性能出发，小数据量可以容器化，大数据量还是物理机；
OpenShift 的服务注册发现用的是 ectd 。这是一个强一致性的 K-V 数据库。 Etcd 心跳默认是 200ms 。所以，如果跨地域、跨可用区的网络不能满足网络延迟小于 200ms ，那每个环境部署单独的容器云，通过类似 ArgoCD 的 gitops 多集群的应用部署。不建议将 OpenShift 集群跨网络...
建议从以下几方面去考虑：1、数据安全问题，例如 容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。2、性能问题， 关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 读写性能。3、网络问题， 要理解 ...
由于典型应用程序将具有跨多个主机运行的容器集群，因此所有这些容器都需要相互通信。因此，要做到这一点，你需要一些能够负载平衡，扩展和监控容器的东西。由于Kubernetes与云无关并且可以在任何公共/私有提供商上运行，因此必须是您简化容器化部署的选择。...
微服务的主要好处是一个服务“类型”可以通过使用多个容器实例和负载均衡来扩展以提供吞吐量。从而保证业务的高并发，稳定性。这也是容器化的一大优点。这个容器化的横向扩展，不是由容器本身实现的，而是通过容器编排引擎如kubernetes来实现的，也就是我们通常所说的pod的水平...
