什么是边缘服务器

边缘服务器为用户提供一个进入网络的通道和与其它服务器设备通讯的功能，通常边缘服务器是一组完成单一功能的服务器，如防火墙服务器，高速缓存服务器，负载均衡服务器，DNS服务器等。

对物联网而言，边缘计算技术取得突破，意味着许多控制将通过本地设备实现而无需交由云端，处理过程将在本地边缘计算层完成。这无疑将大大提升处理效率，减轻云端的负荷。由于更加靠近用户，还可为用户提供更快的响应，将需求在边缘端解决。

物联网应用

全球智能手机的快速发展，推动了移动终端和“边缘计算”的发展。而万物互联、万物感知的智能社会，则是跟物联网发展相伴而生，边缘计算系统也因此应声而出。

事实上，物联网的概念已经提出有超过15年的历史，然而，物联网却并未成为一个火热的应用。一个概念到真正的应用有一个较长的过程，与之匹配的技术、产品设备的成本、接受程度、试错过程都是漫长的，因此往往不能很快形成大量使用的市场。

根据Gartner的技术成熟曲线理论来说，在2015年IoT从概念上而言，已经到达顶峰位置。因此，物联网的大规模应用也开始加速。因此未来5-10年内IoT会进入一个应用爆发期，边缘计算也随之被预期将得到更多的应用。

输入输出设备单元柜。IO柜里面有机架槽和上面的各种IO模块，包括AI、DI、AO、DO模块等，属于输入输出设备单元柜。还有电源模块 通讯模块 （网络模块），接线端子排 保护装置 继电器单元。

买品牌服务器合算，性价比更高。
在稳定性方面表现稍好，同时，品牌服务器一般都配有管理模块和完善的售后服务，简化了用户管理步骤，也能在一定程度上帮助用户节约成本，另外，使用品牌服务器对企业的形象也有一定的提升。

至于性能方面，实际上，与普通电脑一样道理，在性能上起决定性作用的还是处理器、内存、硬盘等几大核心配件，因此，配置相同的品牌机与组装机性能上并无明显差异；再来说说稳定性和售后服务，服务器的稳定性一般说来有两个方面决定，一是配件的品质，由于这个原因所导致的服务器稳定性问题并非组装服务器独有，相同配置情况下的品牌服务器和组装服务器，由配件导致系统不稳定的概率是一样的，第二个原因则是服务器机箱布局设计。感兴趣的话点击此处，了解一下

关于服务器购买的选择，亿万克是一个不错的选择，亿万克旗下产品主要有亚当通用机架式服务器系列、亚当液冷服务器系列及蛟云存储设备系列。其中，亿万克服务器产品采用最新的Intel至强可扩展处理器，针对云、企业、高性能计算、网络、安全和物联网工作负载进行优化，支持海量存储空间，可根据业务需求d性扩容，具备丰富的IO扩展能力，可提升I/O 带宽，为数据中心到边缘的各种工作负载提速。

文件服务器、数据库服务器、邮件服务器。
文件服务器是指在计算机网络中,以文件数据的存储与共享为主要功能的服务器,负责中央存储和数据文件管理,处于同一网络环境。数据库服务器因为数据文件的重要性及数据的文件都较大,数据库服务器一般是指运行在网络中的一台或多台服务器和数据库管理系统软件，邮件服务器。
文件服务器（Fileserver），又称档案伺服器，是指在计算机网络环境中，所有用户都可访问的文件存储设备，是一种专供其他电脑检索文件和存储的特殊电脑。文件服务器通常比一般的个人电脑拥有更大的存储容量，并具有一些其他的功能，如磁盘镜像、多个网络接口。

PLC的
IO柜,就是输入输出设备单元柜；里面有机架槽和上面的各种IO模块，包括AI、DI、AO、DO模块等等，还有电源模块
通讯模块
（网络模块），接线端子排
保护装置
继电器单元
等等
理论上说，如果定义为IO柜了，严格的话，变送器、UPS等不允许放入,在实际中也很少见将体积相对庞大的UPS和需要维护的变送器放入。

HDFS Architecture

Hadoop Distributed File System (HDFS) 是设计可以运行于普通商业硬件上的分布式文件系统。它跟现有的分布式文件系统有很多相通的地方，但是区别也是显著的。HDFS具有高度容错性能，被设计运行于低成本硬件上。HDFS可以向应用提供高吞吐带宽，适合于大数据应用。HDFS 放宽了一些 POSIX 的要求，以开启对文件系统数据的流式访问。HDFS 最初是作为Apache Nutch web 搜索引擎项目的基础设施开发的。HDFS 现在是 Apache Hadoop 核心项目的一部分。

HDFS是主从架构。一个HDFS集群包含一个NameNode，一个管理文件系统命名空间和控制客户端访问文件的master server。以及，若干的 DataNodes，通常集群的每个node一个，管理运行DataNode的节点上的存储。HDFS 发布一个文件系统命名空间，并允许用户数据已文件的形式存储在上面。内部，一个文件被分成一个或多个块，存储在一组DataNodes上。NameNode 执行文件系统命名空间 *** 作，比如：打开、关闭、重命名文件或目录。它还确定块到DataNodes的映射。DataNodes 负责向文件系统客户端提供读写服务。DataNodes 根据 NameNode 的指令执行块的创建、删除以及复制。

NameNode 和 DataNode 是设计运行于普通商业机器的软件。这些机器通常运行 GNU/Linux *** 作系统。HDFS 是Java 语言编写的；任何支持Java的机器都可以运行NameNode or DataNode 软件。使用高移植性Java语言，意味着HDFS可以部署在很大范围的机器上。一个典型的部署就是一台特定的机器只运行NameNode 软件，而集群内的其他机器运行DataNode 软件的一个实例。这种架构不排除一台机器上运行多个DataNodes ，但是在实际部署中很少见。

单 NameNode 节点的存在大大简化了架构。NameNode 是所有HDFS 元数据的仲裁和仓库。系统设计上，用户数据永远不经过NameNode。

HDFS 支持传统的文件分级组织。用户或应用可以创建目录，并在目录内存储文件。 文件系统命名空间的层次结构跟其他文件系统类似；可以创建、删除、移动、重命名文件。HDFS 支持 user quotas 和 access permissions 。 HDFS 不支持软、硬链接。但是，HDFS 架构不排除实现这些功能。

虽然HDFS遵守 文件系统命名约定 ，一些路径和名称 (比如/reserved 和snapshot ) 保留了。比如功能 transparent encryption 和 snapshot 就使用的保留路径。

NameNode 维护文件系统命名空间。任何文件系统命名空间或属性的变化，都会被NameNode记录。 应用可以指定HDFS应维护的文件副本数量。文件副本的数量被称为该文件的复制因子 replication factor 。该信息存储于NameNode。

HDFS 被设计用于在一个大规模集群上跨机器可靠地存储巨大的文件。它以一序列的块的方式存储文件。每个文件都可以配置块尺寸和复制因子。

一个文件除了最后一个块外，其他的块一样大。在 append 和 hsync 添加了可变长度块的支持后，用户可以启动一个新的块，而不用填充最后一个块到配置的块大小。

应用可以指定一个文件的副本数量。复制因子可以在创建的时候指定，也可以以后更改。HDFS的文件只写一次(除了 appends 和 truncates) ，并在任何时候只允许一个 writer 。

NameNode 指定块复制的所有决策。它周期性的从集群的每个DataNodes 接受 Heartbeat 和 Blockreport。Heartbeat 的接受代表 DataNode 工作正常。Blockreport 包含了DataNode上所有块的清单。

副本的位置对HDFS的可靠性和性能至关重要。副本位置的优化是HDFS和其他大多数分布式文件系统的区别。这是一个需要大量调优和经验的特性。Rack-aware 复制策略的目的就是提高数据可靠性，可用性和网络带宽利用率。当前副本位置策略的实现是这个方向的第一步。实施该策略的短期目标是在生产环境验证它，了解其更多的行为，为测试和研究更复杂的策略打下基础。

大型HDFS实例运行在跨多个Rack的集群服务器上。不同rack的两个node通信需要通过交换机。大多数情况下，同一rack内的带宽大于rack之间的带宽。

NameNode 通过在 Hadoop Rack Awareness 内的进程描述 判断DataNode 属于哪个rack id。一个简单但是并非最佳的策略是将副本分布于不同的racks。这可以防止整个机架发生故障时丢失数据，并允许在读取数据时使用多个机架的带宽。该策略在群集中均匀地分布副本，使得组件故障时很容易平衡负载。 但是，该策略会增加写入成本，因为写入 *** 作需要将块传输到多个机架。

一般，复制因子设置为3， HDFS 的分布策略是：如果writer在datanode上则将一个副本放到本地机器， 如果writer不在datanode上则将一个副本放到writer所在机柜的随机datanode 上；另一个副本位于不同机架的node上；最后一个副本位于同一远程机架的不同node上。 该策略减少了机架间的写流量，提升了写性能。机架故障的概率远小于节点故障的概率；此策略不会影响数据可靠性和可用性承诺。但是，在读取数据时，它确实减少了聚合带宽，因为块存储于两个机柜而不是三个机柜内。使用此策略，副本不会均匀的分布于机架上。1/3 副本 位于同一节点， 2/3 副本位于同一机架， 另1/3副本位于其他机架。该策略提升了写性能而不影响数据可靠性和读性能。

如果复制因子大于3，那么第4个及以后的副本则随机放置，只要满足每个机架的副本在(replicas - 1) / racks + 2)之下。

因为 NameNode 不允许 DataNodes 拥有同一个块的多个副本，所以副本的最大数就是DataNodes的数量。

在把对 存储类型和存储策略 的支持添加到 HDFS 后，除了上面介绍的rack awareness外， NameNode 会考虑其他副本排布的策略。NameNode 先基于rack awareness 选择节点，然后检查候选节点有文件关联的策略需要的存储空间。 如果候选节点没有该存储类型， NameNode 会查找其他节点。如果在第一条路径中找不到足够的节点来放置副本，NameNode会在第二条路径中查找具有回滚存储类型的节点。 、

当前，这里描述的默认副本排布策略正在使用中。

为了最小化全局带宽消耗和读取延迟， HDFS 会尝试从最靠近reader的副本响应读取请求。如果在reader节点的同一机架上上存在副本，则该副本有限响应读请求。如果HDFS集群跨多个数据中心，则本地数据中心优先。

启动时，NameNode 会进入一个称为 Safemode 的特殊状态。当NameNode处于Safemode状态时，不会复制数据块。NameNode从DataNodes接收Heartbeat和Blockreport消息。Blockreport包含DataNode托管的数据块列表。每个块都指定了最小副本数。当数据块的最小副本数已与NameNode签入时，该块被认为是安全复制的。在NameNode签入安全复制数据块的已配置百分比（加上额外的30秒）后，NameNode退出Safemode状态。然后，它判断列表内的数据块清单是否少于副本指定的数量。NameNode 然后复制这些块给其他 DataNodes。

HDFS 命名空间由 NameNode 存储。NameNode 使用事务日志 EditLog 来持久化的保存系统元数据的每次变更。比如，在HDFS创建一个新文件，NameNode会在 EditLog 插入一条记录来指示该变更。类似的，变更文件的复制因子也会在 EditLog 插入一条新记录。NameNode 以文件的形式，将 EditLog 保存在本地OS文件系统上。整个文件系统命名空间，包括块到文件的映射、文件系统属性，都存储于名字为 FsImage 的文件内。 FsImage 也以文件的形式，存储在NameNode的本地文件系统上。

NameNode 将包含整个文件系统和块映射的image保存在内存中。当NameNode启动时，或检查点被预先定义的阈值触发时，它会从磁盘读取 FsImage 和 EditLog ，把 EditLog 内的事物应用到内存中的FsImage，再将新版本刷新回磁盘的新 FsImage 。然后会截断旧的 EditLog ，因为它的事物已经应用到了持久化的 FsImage 上。 这个过程称为检查点 checkpoint 。检查点的目的是通过对文件系统元数据进行快照并保存到FsImage，来确保HDFS拥有文件系统元数据的一致性视图。尽管读取 FsImage 是高效的，但是对 FsImage 直接增量修改是不高效的。不是对每次编辑修改 FsImage ，而是将每次编辑保存到 Editlog 。在检查点期间，将 Editlog 的变更应用到 FsImage 。一个检查点可以在固定周期(dfsnamenodecheckpointperiod)(以秒为单位)触发，也可以文件系统事物数量达到某个值(dfsnamenodecheckpointtxns)的时候触发。

DataNode 在本地文件系统上以文件的形式存储 HDFS data 。DataNode 不知道 HDFS 文件。它将HDFS data 的每个块以独立的文件存储于本地文件系统上。DataNode 不在同一目录创建所有的文件。而是，使用heuristic来确定每个目录的最佳文件数量，并适当的创建子目录。在一个目录创建所有的本地文件是不好的，因为本地文件系统可能不支持单目录的海量文件数量。当DataNode启动的时候，它扫描本地文件系统，生成与本地文件系统一一对应的HDFS数据块列表，然后报告给NameNode。这个报告称为 Blockreport。

所有的HDFS通信协议都在TCP/IP协议栈上。客户端与NameNode指定的端口建立连接。与NameNode以ClientProtocol 通信。DataNodes与NameNode以DataNode Protocol进行通信。远程过程调用(RPC)封装了Client Protocol 和 DataNode Protocol。设计上，NameNode从不启动任何RPCs。相反，它只应答DataNodes or clients发出的RPC请求。

HDFS的主要目标是可靠的存储数据，即使是在故障的情况下。常见故障类型有三种： NameNode failures , DataNode failures 和 network partitions 。

每个DataNode都周期性的向NameNode发送心跳信息。 一个 network partition 可能导致DataNodes子集丢失与NameNode的连接。NameNode会基于心跳信息的缺失来侦测这种情况。NameNode将没有心跳信息的DataNodes标记为 dead ，并不再转发任何IO请求给它们。任何注册到dead DataNode的数据对HDFS将不再可用。DataNode death会导致某些块的复制因子低于它们指定的值。NameNode不断跟踪需要复制的块，并在必要时启动复制。很多因素会导致重新复制：DataNode不可用，副本损坏，DataNode上硬盘故障，复制因子增加。

标记 DataNodes dead 的超时时间保守地设置了较长时间 (默认超过10分钟) 以避免DataNodes状态抖动引起的复制风暴。对于性能敏感的应用，用户可以设置较短的周期来标记DataNodes为过期，读写时避免过期节点。

HDFS 架构支持数据再平衡schemes。如果一个DataNode的空余磁盘空间低于阈值，sheme就会将数据从一个DataNode 移动到另外一个。在某些文件需求突然增长的情况下，sheme可能会在集群内动态的创建额外的副本，并再平衡其他数据。这些类型的数据再平衡schemes还没有实现。

有可能从DataNode获取的数据块，到达的时候损坏了。这种损坏可能是由于存储设备故障、网络故障、软件bug。HDFS客户端软件会HDFS的内容进行校验。当客户端创建HDFS文件的时候，它计算文件每个块的校验值，并以独立的隐藏文件存储在同一HDFS命名空间内。当客户端检索文件时候，它会校验从每个DataNode获取的数据，是否与关联校验文件内的校验值匹配。 如果不匹配，客户端可以从另外拥有副本块的DataNode检索。

FsImage 和 EditLog 是HDFS的核心数据结构。这些文件的损坏将导致HDFS实例异常。 因此，NameNode可以配置为支持多 FsImage 和 EditLog 副本模式。任何对 FsImage or EditLog 的更新都会导致每个 FsImages 和 EditLogs 的同步更新。 FsImage 和 EditLog 的同步更新会导致降低命名空间每秒的事物效率。但是，这种降级是可以接受的，因为HDFS应用是数据密集型，而不是元数据密集型。当NameNode重启的时候，它会选择最新的一致的 FsImage 和 EditLog 。

另外一种提供故障恢复能力的办法是多NameNodes 开启HA，以 shared storage on NFS or distributed edit log (called Journal)的方式。推荐后者。

Snapshots - 快照，支持在特定时刻存储数据的副本。快照功能的一个用法，可以回滚一个故障的HDFS实例到已知工作良好的时候。

HDFS被设计与支持超大的文件。与HDFS适配的软件都是处理大数据的。这些应用都只写一次，但是它们会读取一或多次，并且需要满足流式读速度。HDFS支持文件的 一次写入-多次读取 语义。 HDFS典型的块大小是128 MB。因此，HDFS文件被分割为128 MB的块，可能的话每个块都位于不同的DataNode上。

当客户端以复制因子3写入HDFS文件时，NameNode以 复制目标选择算法 replication target choosing algorithm 检索DataNodes 列表。该列表包含了承载该数据块副本的DataNodes清单。然后客户端写入到第一个DataNode。第一DataNode逐步接受数据的一部分，将每一部分内容写入到本地仓库，并将该部分数据传输给清单上的第二DataNode。第二DataNode，按顺序接受数据块的每个部分，写入到仓库，然后将该部分数据刷新到第三DataNode。最终，第三DataNode将数据写入到其本地仓库。
因此，DataNode从管道的前一个DataNode获取数据，同时转发到管道的后一个DataNode。因此，数据是以管道的方式从一个DataNode传输到下一个的。

应用访问HDFS有很多方式。原生的，HDFS 提供了 FileSystem Java API 来给应用调用。还提供了 C language wrapper for this Java API 和 REST API 。另外，还支持>