Tungsten Fabric如何支撐大規(guī)模云平臺

作者:楊雨

“MTU的值設(shè)置多少合適呢?現(xiàn)在最佳實踐是設(shè)置到9000。”

“其實OpenFlow只是一個概念,從這幾年SDN的發(fā)展來看,它并沒有成為一個事實的標準。”

“大規(guī)模云平臺對SDN的要求,第一是網(wǎng)絡(luò)基礎(chǔ)架構(gòu)要可擴展,第二是控制器可擴展,第三是數(shù)據(jù)平面無集中式單點,第四是跨集群的擴展網(wǎng)絡(luò)。”

“在基礎(chǔ)架構(gòu)上,如果用Tungsten Fabric,只要是用于生產(chǎn)環(huán)境的話,選擇IP CLOS架構(gòu)就行,沒必要再去折騰Fabric等二層架構(gòu)。”

“Tungsten Fabric的本質(zhì)是基于MPLS VPN的SDN。”

“跨集群的互聯(lián),或者叫多云互聯(lián),主要有兩種模式:基于控制器之間的互聯(lián),基于Cloud Gateway之間的互聯(lián)。”

本文整理自TF中文社區(qū)技術(shù)代表楊雨在TF中文社區(qū)“2020第一次Meetup”上的演講,分享Tungsten Fabric對大規(guī)模云平臺的支持。本文已經(jīng)主辦方和演講者審閱授權(quán)發(fā)布。

在TF中文社區(qū)1月7日的“2020第一次Meetup”活動上,來自Tungsten Fabric技術(shù)研發(fā)和一線使用者、關(guān)注多云互聯(lián)的從業(yè)者、開源SDN的愛好者們互相切磋、支招,現(xiàn)場氣氛熱烈,精彩內(nèi)容不斷。Tungsten Fabric在中國的廣泛應用正在越來越真切地走來。

本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領(lǐng)取。

今天的分享偏技術(shù)一些,首先我們來看SDN的本質(zhì),然后從Tungsten Fabric架構(gòu)上解析為什么比OVS更好,為什么能支撐更大的場景。

先來看云對網(wǎng)絡(luò)的要求。首先是租戶隔離,IaaS就是多租戶,對于地址重用的要求,以VLAN的傳統(tǒng)方式也是可以實現(xiàn)的。另外,傳統(tǒng)VXLAN的協(xié)議或OVS的協(xié)議,只提供二層隔離的能力,沒有三層隔離的能力,只要你的機器綁到外網(wǎng)IP,或者綁到公共的路由層面上,三層是可以互通的,所以說在租戶隔離的層面,也有三層隔離的需求。

其次,云需要網(wǎng)絡(luò)支持虛擬機跨機柜的遷移。VXLAN的話還要跨數(shù)據(jù)中心大二層,不是說不可以實現(xiàn),但除了網(wǎng)絡(luò)要求,還有存儲的要求,比較難。虛擬機跨機柜的遷移,最難的是什么?傳統(tǒng)網(wǎng)絡(luò)架構(gòu),就是接入-匯聚-核心,路由器以下都是二層架構(gòu),機器可以在不同機架上遷移,但一個數(shù)據(jù)中心,云足夠大的時候,二層基礎(chǔ)網(wǎng)絡(luò)是支撐不了整個云的,不同機架在不同三層里面,這時虛擬機做遷移就要要求IP地址不能變。

另外,還有網(wǎng)絡(luò)功能和服務(wù)的要求。在云上面都是共享的資源池,如果以負載均衡為例,將一個性能強大的硬件負載均衡虛擬化給多個租戶使用,還是切換成小的負載均衡虛擬機實例給不同租戶使用?這里就提出網(wǎng)絡(luò)虛擬化和網(wǎng)絡(luò)功能虛擬化的需求,來支撐IaaS的運行。

網(wǎng)絡(luò)虛擬化,主要應用的是Overlay的技術(shù),是SDN用到的其中一個技術(shù),用的比較多、比較標準的技術(shù),包括VXLAN、GRE、STT、GENEVE,以及Tungsten Fabric用到的MPLSoverUDP和MPLSoverGRE,主要的方式,是把二層的幀在vTEP上進行三層封裝,通過VXLAN隧道傳輸?shù)綄Χ恕?/p>

這樣做的好處是,增加了租戶的數(shù)量,傳統(tǒng)VLAN是4096,如果VXLAN就是2的24次方;其次底層傳輸基于IP網(wǎng)絡(luò),擴展性遠大于二層網(wǎng)絡(luò),使得網(wǎng)絡(luò)能擴展,虛擬機在不同物理網(wǎng)段上遷移。但同樣也帶來一些工作,如何讓兩邊的設(shè)備建立通信?第一建立VXLAN隧道,這是SDN控制器要做的事,第二是交換兩邊的MAC地址信息。

TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細演示操作過程,并解答關(guān)于Tungsten Fabric和K8s的一切問題。關(guān)注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”領(lǐng)取。

有兩個VM,在兩個不同的主機上,就是通過Overlay來解決二層通信問題的。比如ESX1要和ESX2通信,ping的時候首先發(fā)ARP請求,那對應的MAC地址是多少?對于VXLAN來說就要有一張轉(zhuǎn)發(fā)表,MAC2需要通過VTEP2的IP,去做一個封包,再傳輸?shù)絍TEP2,解封裝后,再傳輸?shù)较鄳臋C器里去。怎么建立這個轉(zhuǎn)發(fā)表?就是SDN需要去做的事情。

一種是自學習,只要VM1發(fā)了一個ARP請求,到達vTEP網(wǎng)關(guān),它就會去洪泛請求,廣播到和它建立隧道的vTEP節(jié)點上去,看誰反饋ARP reply,就知道對端的IP地址,可以建立一個轉(zhuǎn)發(fā)表。但這樣會有很多消耗,ARP地址也有老化的過程,一旦老化,就需要重新去學,直觀體驗是ping包時間會很長。如果是大規(guī)模的網(wǎng)絡(luò),頻繁洪泛,會對網(wǎng)絡(luò)可靠性帶來很大的挑戰(zhàn)。

SDN大部分情況下是和云管平臺做結(jié)合,知道在這個虛擬化服務(wù)器上,有哪些虛擬機,提前把MAC地址表或轉(zhuǎn)發(fā)表下發(fā)到vTEP設(shè)備上,這就是SDN控制平面要做的事情。

在Open vSwitch這個方案里面,就是通過數(shù)據(jù)庫和RabbitMQ,去下發(fā)一個OVSDB的命令,建立相應的流表,讓虛擬機知道要往哪兒走。Tungsten Fabric也有相應的機制,后面會介紹。

數(shù)據(jù)平面的作用,就是根據(jù)轉(zhuǎn)發(fā)表,對二層的幀進行轉(zhuǎn)發(fā),另外進行封包和解包。這里提一下MTU,這是這個二層的值,幀的transfer unit,為什么要設(shè)置很大?首先VXLAN協(xié)議會增加一些Hdr,UTP的Hdr,VXLAN的Hdr,封包的時候如果不做處理的話會超過1500,網(wǎng)卡會不發(fā)這個幀。早期做OpenStack經(jīng)常會遇到trouble shooting的MTU問題,后來解決方案是通過DHCP的Agenter,設(shè)置了一個參數(shù),如果網(wǎng)卡MTU是1500,就默認為14XX,自動降低,這樣虛擬機的數(shù)據(jù)幀才能通過二層網(wǎng)卡。那么MTU的值設(shè)置多少合適呢?現(xiàn)在最佳實踐是設(shè)置到9000。在vTEP這一塊就是封包和轉(zhuǎn)發(fā),根據(jù)實際測試,如果增加MTU值,對吞吐量有很大的提高。

剛才說了SDN做的事情,控制下發(fā)轉(zhuǎn)發(fā)表和傳輸,接下來說一下SDN的分類。按流派來區(qū)分,SDN可分為軟件和硬件,區(qū)別就是vTEP是在vRouter上,還是在交換機的硬件轉(zhuǎn)發(fā)上,看解封包在哪里。硬件一般都是私有協(xié)議,像Cisco用的就是OPFlex。軟件也有很多不同的項目,其中Tungsten Fabric是最產(chǎn)品化的一個。

按照控制器分類,有集中式和分布式。集中式的控制器有OpenFlow、OVSDB,以及Tungsten Fabric使用XMPP(一個聊天的協(xié)議)。我們可以把Neutron的Open vSwitch理解為OVSDB協(xié)議,Neutron是通過RabbitMQ把信令下發(fā)到具體的計算節(jié)點,計算節(jié)點的OVS Agent通過OVSDB的命令,把相應的流表增加到OVSDB交換機。

分布式的控制器,比如EVPN-VXLAN,就是使用了MP-BGP。

大家覺得哪種形式的控制器會更好一點呢?目前用OpenDaylight的項目有哪些?華為,華三等都在用,其控制器的SDN架構(gòu)就是參照OpenFlow來做的。有些廠商自己有研發(fā)能力,基于自身的硬件設(shè)備,可以開發(fā)一個比較完善的產(chǎn)品。但在開源社區(qū),很少看到一個成功的OpenDaylight項目,只是提供了一個框架和一些組件,不能很快基于開源項目run起來。其實OpenFlow只是一個概念,從這幾年SDN的發(fā)展來看,它并沒有成為一個事實的標準。

反而是OVSDB起來了,應用在Neutron軟件的控制,還有交換機的控制上。比如Tungsten Fabric早期的BMS實現(xiàn),虛擬機要和裸機通信,裸機通過VLAN TAG,上到TOR交換機,再通過VLAN到VXLAN的轉(zhuǎn)換,到達虛擬網(wǎng)絡(luò)。其中VLAN到VXLAN的轉(zhuǎn)換,就是通過OVSDB協(xié)議下發(fā)的。你的交換機,理論上只要支持OVSDB協(xié)議,就可以做BMS場景。

我自己更傾向于這種分布式的控制器。因為集中式的永遠會有瓶頸,無論是軟件瓶頸,還是性能瓶頸。而EVPN-VXLAN的核心協(xié)議是MP-BGP,BGP的擴展性有多大?看看現(xiàn)在Internet骨干網(wǎng),跑的就是BGP協(xié)議。

MP-BGP的協(xié)議,通過控制器下發(fā)流表信息,再通過BGP協(xié)議去交互,使用的時候只要針對你的相應架構(gòu),去做相應BGP協(xié)議的擴展性設(shè)計就可以。

針對Tungsten Fabric來說,其實是集中式和分布式兩種流派的融合,既用到集中式的架構(gòu),在對外的連接上,又采用了分布式控制器的技術(shù)。

總結(jié)大規(guī)模云平臺對SDN的要求,第一是網(wǎng)絡(luò)基礎(chǔ)架構(gòu)要可擴展。如果采用二層架構(gòu),瓶頸就是在基礎(chǔ)架構(gòu)上,受限于交換機的端口數(shù),二層交換機采用生成樹協(xié)議,對于大規(guī)模網(wǎng)絡(luò)平臺,如果運維水平較差,接出一個環(huán)路出來,就很危險。

第二,控制器是可擴展的。無論集中式還是分布式,在架構(gòu)上一定是可擴展的,至于能支持多大的量,就是代碼實現(xiàn)的問題了。

第三,數(shù)據(jù)平面無集中式單點。談到SDN的實際應用,運維是一個比較大的挑戰(zhàn),無論是做開發(fā)還是做運維出身的人,最重要的是理解虛擬機之間,虛擬機到外網(wǎng)之間,數(shù)據(jù)流量是怎樣的?應該通過什么命令去看這些流量,去trouble shooting,就像以前傳統(tǒng)網(wǎng)絡(luò)運維怎么去抓包一樣。對于擴展性來說,要實現(xiàn)傳統(tǒng)網(wǎng)絡(luò)的SNAT、floating IP等,每個項目都有不同的實現(xiàn)方式,實現(xiàn)過程中沒有單點的話,在架構(gòu)上就是可以擴展的。

第四,跨集群的擴展網(wǎng)絡(luò)。架構(gòu)上無論怎樣擴展,總是有極限的,對于一個單集群來說,總會到達一個瓶頸。如果要建一個更大的集群,可以橫向擴展多個集群出來,形成一個大的資源池。那么面臨的問題是,網(wǎng)絡(luò)是否需要互通。如果部署一個高可用業(yè)務(wù),跨集群的情況如何做互通,主流的一些高可用組件,需要跨兩個集群二層互通,都需要SDN去支持這樣的需求。

在基礎(chǔ)架構(gòu)上,如果用Tungsten Fabric,只要是用于生產(chǎn)環(huán)境的話,選擇IP CLOS架構(gòu)就行,沒必要再去折騰Fabric等二層架構(gòu)。IP CLOS可以帶來足夠的擴展性和高性能,包括沒有供應商鎖定,建完以后基本不需要再動。

Leaf就是架頂式交換機,下面是子網(wǎng),不同機架用不同子網(wǎng),上層通過三層網(wǎng)關(guān)路由做通信,最主要的就是Leaf Spine之間三層怎么交互。瞻博網(wǎng)絡(luò)有個文檔介紹IP CLOS的白皮書,對OSPF、ISIS、BGP進行了控制平面上的對比,最佳建議是用eBGP來做交互。

Tungsten Fabric的本質(zhì)是基于MPLS VPN的SDN。原來的VPN是解決多個site之間的互聯(lián),控制平面是BGP協(xié)議。到了數(shù)據(jù)中心里面,云之間的互聯(lián),一個物理機可以看做一個site,不同物理機之間借助VPN建立不同的隧道來打通,這就是Tungsten Fabric的本質(zhì)。不同之處在于控制平面,Tungsten Fabric用的是集中式的控制器并通過XMPP協(xié)議控制vRouter的路由表。

簡單看一下Tungsten Fabric的功能架構(gòu),在多云支持上,包括VMware、OpenStack容器、BMS;網(wǎng)絡(luò)功能上,二層網(wǎng)絡(luò)、三層網(wǎng)絡(luò)、DHCP、DNS、QoS、防火墻、LB等都是支持的。

在部署的時候,控制器主要分為兩種節(jié)點,一種是Analytics Cluster分析節(jié)點,主要做流的可視化。另外一種Controller節(jié)點用來控制網(wǎng)絡(luò),分為Configuration和Control Node,前者提供API,對接Neutron等云管平臺,API通過創(chuàng)建一個pod,在Configuration上記錄數(shù)據(jù)庫,轉(zhuǎn)換成相應的IF-MAP,控制器通過XMPP命令在vRouter上創(chuàng)建相應的接口,再把接口信息傳給不同的vRouter或外部網(wǎng)關(guān)及硬件設(shè)備,控制器核心協(xié)議是BGP協(xié)議。

控制器在整個Tungsten Fabric里就是一個router reflector,把所有的二層接口、MAC接口信息,三層路由信息全部存在這里,分發(fā)到不同的vRouter上面。對于云內(nèi)的vRouter,用XMPP推送,對于云外的Gateway等,通過BGP推送。

其中,NETCONF協(xié)議不是用來推送路由信息的,主要用于和網(wǎng)絡(luò)硬件設(shè)備的一些配置下發(fā)。比如Tungsten Fabric中增加一個BMS服務(wù)器接入到Tungsten Fabric管理的虛擬網(wǎng)絡(luò),Tungsten Fabric中的Device Manager會通過NETCONF將VLAN接口的配置和下發(fā)到TOR交換機,通過NETCONF建立接口。然后Tungsten Fabric控制器再通過OVSDB協(xié)議或EVPN-VXLAN協(xié)議去配置相應的VLAN-VXLAN的橋接網(wǎng)關(guān)。如果需要把虛擬網(wǎng)絡(luò)擴展到Gateway,NETCONF也會幫助創(chuàng)建相應的Routing instance配置。路由層面的交換信息,還是通過BGP來實現(xiàn)。

TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細演示操作過程,并解答關(guān)于Tungsten Fabric和K8s的一切問題。關(guān)注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”領(lǐng)取。

Tungsten Fabric用到的數(shù)據(jù)庫,都是最近8年才有的,比如分布式數(shù)據(jù)庫的Cassandra、Zoo Keeper、RabbitMQ,在架構(gòu)上是高可用、可擴展的,具體能擴展到多大的量,還是要看代碼實現(xiàn)。反過來看Neutron,本質(zhì)就是一個數(shù)據(jù)庫,記錄了所有的信息,把所有的流表下發(fā)下去。

Tungsten Fabric的數(shù)據(jù)平面主要是通過vRouter來做轉(zhuǎn)發(fā),vRouter agent在user namespace的進程,安排控制器基于XMPP連接拿到一些信息,再下發(fā)到kernel的轉(zhuǎn)發(fā)平面。這里提供了二層隔離和三層隔離的功能,如果說同一個網(wǎng)絡(luò)的虛擬機,接在同一個vRouter下面,雙方的通信就在這里完成。不同租戶的網(wǎng)絡(luò)虛擬機,接了不同的VRF、Routing instance,也是不能通信的。

vRouter內(nèi)置了很多網(wǎng)絡(luò)功能,比如DNS。Tungsten Fabric的DNS會根據(jù)主機的DNS配置來解析,如果遇到問題,可以檢查一下主機的DNS有沒有問題。DHCP應答也在這里,Neutron就不一樣,專門有一個DHCP agent跑在一個節(jié)點上,OVS在大規(guī)模情況下,如果接了超過1500個接口,基本上就會出現(xiàn)丟包,并且經(jīng)常出問題。

Security Group在OVS的實現(xiàn)是通過和linux bridge關(guān)聯(lián)的iptables實現(xiàn)的,而在vRouter就是通過內(nèi)置的ACL功能實現(xiàn)。Network Policy就是一個分布式的防火墻。Floating IP也是在vRouter做了一個NAT出去。

這里多談一下Link-Local,它的場景是什么?作為一個云服務(wù)商,要向客戶提供NTP服務(wù)、ATP、YUM源、等公共服務(wù)。怎么讓虛擬機在虛擬網(wǎng)絡(luò)內(nèi)訪問到一個公共服務(wù)呢?一種方式是把這些網(wǎng)絡(luò)的路由打通,因為需要一個VTEP出口,通過cloud gateway把公共路由導進去,這樣帶來一個問題,所有ATP流量、下載流量都要通過cloud gateway,流量會跟大。Tungsten Fabric提供一個Link-Local的模式,就是一個169.254的地址,在網(wǎng)絡(luò)標準里只有一跳。在OpenStack虛擬機或AWS虛擬機里面,metadata服務(wù)就是通過169.254提供的。本機沒有這個路由,到網(wǎng)關(guān)上對地址做一層NAT,本機的NAT就會訪問到配置的Link-Local映射,繼而訪問到內(nèi)部的服務(wù)。

在沒有增強的前提下,實測Neutron的OVS VXLAN的性能(只做MTU的優(yōu)化),最多達到兩個千兆的性能。而vRouter在不做任何優(yōu)化的前提下,能達到七、八千兆的性能。當然也可以利用DPDK、Smart NIC來做優(yōu)化,或者利用SR-IOV的透傳功能。

再來看看Tungsten Fabric的Packet交互。無論是同網(wǎng)段還是不同網(wǎng)段,虛擬機之間的交互,都是在vRouter層面轉(zhuǎn)發(fā)的,不會經(jīng)過一個集中式的gateway。所以在虛擬機之間的數(shù)據(jù)交互層面,是沒有單點的。

另外一個比較重要的場景是SNAT。在OpenStack里面,如果虛擬機接了一個vRouter,可以通過vRouter的SNAT功能去訪問external的網(wǎng)段。Tungsten Fabric本身其實不提供SNAT,但也實現(xiàn)了SNAT功能,通過NS router(跑在計算節(jié)點的一個IP tables)做一個SNAT的轉(zhuǎn)發(fā),如果虛擬機要訪問一個非本網(wǎng)關(guān)的網(wǎng)絡(luò),先到gateway,轉(zhuǎn)發(fā)后,再通過vRouter連接external的網(wǎng)絡(luò)。這里NS router的創(chuàng)建,需要OpenStack nova的scheduler來配合。

對于每一個網(wǎng)絡(luò),都會有一個router去做轉(zhuǎn)發(fā),如果量太大,瓶頸可能就在NS router這里,但不會影響其它的網(wǎng)絡(luò)。

只要不在云內(nèi),都可以叫外網(wǎng),要出外網(wǎng)有兩種方式:第一種是Floating IP,在vRouter做了一個NAT,把NAT后的IP通過MPLS over GRE的隧道,發(fā)布到Cloud Gateway的某個VRF里面,和外網(wǎng)通信。

第二種外部互聯(lián)的場景,假如要提供一個云服務(wù),可以針對不同的運營商做不同的flouting IP,如果做L3 VPN或L2 VPN的專線接入服務(wù),可以通過cloud gateway接入到不同的MPLS網(wǎng)絡(luò),再把虛擬網(wǎng)絡(luò)路由到相應的VRF,整個就都連通了。這也是Tungsten Fabric強大的地方,MPLS VPN是和傳統(tǒng)的網(wǎng)絡(luò)天然互聯(lián)互通的。

跨集群的互聯(lián),或者叫多云互聯(lián),主要有兩種模式。

第一種是基于控制器之間的互聯(lián),把VPN、網(wǎng)絡(luò)和接口的信息,通過控制器之間建立EBGP連接來傳輸,這種方案叫Federation。

兩邊的vRouter只要三層可達就可以,比如一邊的B1要訪問另一邊的B3,兩邊是不同的控制器和VPN,MPLS VPN有個route target,一邊export一邊import,路由表看到另一邊的路由,進行路由信息交互,從而建立二層或者三層連接。Federation的方案是在控制器層面實現(xiàn)的,比較適合于同一個地域,同一個數(shù)據(jù)中心,有比較近的連接的情況。

第二種模式是通過cloud gateway之間的互聯(lián),把網(wǎng)絡(luò)的不同VRF,在cloud gateway之間建立EBGP鄰居,手動配置去import或export不同的RT,實現(xiàn)跨云的連接。需要注意的是,兩邊是不同的集群,IP地址管理不一樣的,分配地址的時候,要避免IP地址的重疊。

最后,和Neutron OVS進行對標的話,Tungsten Fabric可以說是完勝的。

基礎(chǔ)網(wǎng)絡(luò)方面,Tungsten Fabric可以擴展,Neutron OVS目前只能用二層網(wǎng)絡(luò),無論集中式還是分布式,floating IP下沉到計算節(jié)點這一層,目前的組件里都沒有成熟的BGP方案,能夠把floating IP發(fā)布到邊界網(wǎng)關(guān),OVS DVR和邊界網(wǎng)關(guān)只能通過二層連接。

對比架構(gòu)方面,Tungsten Fabric是可擴展的,3個節(jié)點性能不夠,可以擴展到5個節(jié)點。Neutron OVS雖然是一個高可用架構(gòu),通過MySQL集群實現(xiàn)數(shù)據(jù)庫高可用,通過K8s實現(xiàn)API高可用,但計算邏輯不是分布式的,嚴重依賴RabbitMQ。如果使用DVR模式,每個計算節(jié)點要部署四個agent,帶來更多的topic,對RabbitMQ的性能是很大的挑戰(zhàn),只要出現(xiàn)一個RabbitMQ宕機或網(wǎng)絡(luò)抖動,會馬上執(zhí)行集群恢復機制,導致RabbitMQ很快死掉。

另外,在轉(zhuǎn)發(fā)平面上,Open vSwitch的性能沒有vRouter好;Tungsten Fabric的網(wǎng)絡(luò)功能更豐富,而Neutron的Octavia等原生LBaaS組件也有待成熟;多云互聯(lián)方面Tungsten Fabric基于MPLS VPN;和網(wǎng)絡(luò)設(shè)備的交互方面,Neutron只有ironic的networking generic switc driver,Tungsten Fabric支持BGP、NETCONF、EVPN-VXLAN等,基于標準的協(xié)議,涵蓋了瞻博網(wǎng)絡(luò)、思科、華為、銳捷等廠商的設(shè)備。

今天就先分享到這里。謝謝大家!

本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領(lǐng)取。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。