行业

为何互操作性很难:关注的多重性

发表2016年12月5日
Dharma Indurthy着

在Redox,我们着手解决一个巨大的问题:互操作性。这不是一个原子性的问题;它可分为许多更基本的难题。我们着手解决互操作性 因为 这具有挑战性,解决起来非常有价值。这两个方面都使Redox成为令人兴奋的工作场所。

但是什么使问题变得困难呢?互操作性是常识 很难,但较不常见的是深刻理解其成因。我认为,造成互操作性及其可分割的部分如此之多的主要因素是,我们工作的空间中存在许多必要的问题。其中一些问题是:

解决任何给定问题的所有这些问题非常困难。此外,这些问题是耦合的,因此为一个设计可能会有助于或损害另一个。除了技术解决方案外,通常还会存在其他人为问题,因此,在工程中隐含一些功能已成为其提倡者。为了让您了解Redox的情况,让我们考虑一个相当基本的问题,并深入研究我们为解决其中一些问题而做出的努力。

问题:将卫生系统连接到氧化还原

发挥功能

解决这个问题的功能并不难。将我们的讨论限制在HL7v2领域(这是目前正在进行的大多数医疗保健集成的标准),事实证明,卫生系统的技术已经发展为构建通过传输控制协议(TCP)发送数据的接口引擎。 TCP是一种用于发送信息的优良协议,可确保从源到目标传输有效载荷时的保真度,它是您可能熟悉的大多数数据传输的基础,例如在Web浏览器和它正在浏览的任何Web服务器之间往返。因此,如果我们唯一关心的是功能,我们将设计如下:


在上图中,我们(氧化还原)向我们的合作伙伴公开了一个端点以发送给它,即IP地址和端口,而Health System将使用其接口引擎来作为目标。我们将在承载我们应用程序的实例之间分配流量。如果我们假设该应用程序可跨主机(RedoxEngine是可扩展的)进行扩展,则应用程序服务器的数量将是可变的,并且需要构建负载均衡器以自动检测更改并重新配置。如果Redox需要发送到卫生系统,即如果某个应用程序向我们发送了用于Medical Center的有效负载,则RedoxEngine将使用其为入站接口公开的任何IP和端口将其发送回Health System接口引擎。

这很容易。这个方案是如此简单,以至于它也很容易使用和维护。但是最明显的问题是它并不安全。 TCP流量周围没有本机加密,因此任何拦截流量的人都会获得PHI的宝库。不好。

发挥功能性和安全性

为了增加安全性,Redox设置了带有运行状况系统的虚拟专用网络(VPN)。这使我们可以私下共享数据,几乎就像Redox是在运行状况系统中安装的。的 虚拟 VPN中的“加密”表示基于加密建立了隐私,因此,尽管数据通过Internet传输,但只有具有正确密钥的网络才能对其进行解密。所以现在,我们最终得到如下配置:

连接的每一端,即医学中心和Redox,现在都有一个称为VPN网关的设备。双方使用一种工具来定义公开的本地IP,允许的远程IP以及用于加密和解密数据的密钥。这构成了网络隧道。医疗中心设置网络规则,以将旨在用于Redox的流量路由到其VPN网关。同样,为了从Redox发送回健康系统,Redox中的网络规则必须将用于Medical Center的流量路由回我们的VPN网关。然后,网关通过加密隧道将其中继到远程网络。

不幸的是,这增加了很多复杂性并且损害了可用性。至少在Redox方面,我们需要扩展到数百或数千个VPN,这需要维护很多配置。如果运行状况系统和Redox使用相同的IP范围,我们还使用防火墙工具来转换IP,以避免冲突。我们使用相同的工具来确保每个运行状况系统仅发送到其允许的端口。在确保卫生系统配置不会与其他任何配置冲突的同时,以有组织的方式进行构建具有挑战性。健康系统必须维护自己的VPN专用设备。另外,添加任何新的必需设备所固有的功能会使您面临另一个故障点。

具有功能性,安全性和可用性

为了安全和可用,我们需要冗余。在云中操作时,您不能指望任何不受管理的设备。因为我们只能使用HIPAA兼容工具,所以我们可以自我管理很多基础架构,因此必须管理基础架构故障。以下是我们需要获得高可用性的示例。

在这种情况下,我们有一个辅助负载平衡器和一个辅助VPN网关。如果我们的主实例发生故障,这为我们提供了现成的备份。但是,未显示会导致这种情况的业务逻辑。我们需要考虑不同的故障模式,并实施逻辑以快速检测和解决故障。

如果我们丢失了主负载均衡器,则需要开始将流量定向到辅助负载均衡器。这意味着我们需要

  1. 检测主负载均衡器的故障
  2. 重新配置Redox VPN以将入站流量路由到辅助负载均衡器

据推测,辅助负载平衡器在配置最新方面一直与主要负载平衡器保持同步,这就是我们要做的全部工作。

更为复杂的情况是,如果我们丢失了VPN主节点。在这种情况下,我们需要执行以下操作:

  1. 检测主要VPN网关的故障
  2. 将VPN网关的公共IP重新分配给辅助网关(由于网关在Internet上代理隧道,因此它们各自的公共IP就是用来开始建立隧道的工具.AWS允许预配置可重新分配给该IP的公共IP(EIP)其他电器)。
  3. 获取最新的配置列表(理想情况下,我们使用一个事实来源来更新配置。对于Redox,这存储在Amazon的Simple Storage Service中)。
  4. 更新所有配置和防火墙设置,以将旧主数据库的内部IP重新分配给新主数据库的内部IP。
  5. 更新网络路由规则,以通过VPN将来自Redox的出站流量发送到Medical Center。

事实证明,如果进行复杂的操作,这是可行的。完成后(在检测到故障的几秒钟内发生),将恢复故障的VPN网关服务的所有VPN隧道。 像这样成功进行演习的隐含结果是拥有可靠的监视和警报解决方案,并考虑了失败模式 故障转移过程,与受影响方的有效沟通等。

我们的多重关注

该示例尚未解决可伸缩性和性能的问题。为此,我们必须构建一个单独的彻底的设备来测试我们的VPN设备上的负载,因此我们对网关可以处理的内容有所了解。另外,随着我​​们的解决方案变得越来越复杂,我们将付出复杂性的代价。曾经可用且易于维护的功能现在已在每个卫生系统中具有多层配置,以及严格的监视和警报要求。因此,我们必须回头并确保将我们的工具组织得尽可能易于维护。最后,我们必须倡导我们的解决方案,将其暴露给内部以及与我们合作的组织进行审查。

这是我们在Redox所做的工作。好消息是我们 考虑到我们关注的多个问题,我们在设计中尽可能做到了这一点。满足所有这些期望既艰巨又令人激动。这是我们空间的本质,这就是为什么我们做我们做的事情。