دانلود رایگان مقاله یک سیستم مدیریت شبکه برای رسیدگی به جریان های داده های علمی

چکیده

          انتقال های اطلاعات علمی حجیم اغلب با سرعت های بالایی انجام می شوند که این خود باعث نوسان افزایش یافته در ترافیک اینترنت می شود. به منظور محدود کردن اثرات مضر این چنین جریان های حجیم با سرعت بالا، که به آنها جریان های α گفته می شود، برروی جریان های ویدیو/صوت حساس به تاخیر، یک سیستم مدیریت شبکه به نام سیستم مهندسی ترافیک جریان آلفا (AFTES)  برای مهندسی ترافیک درون قلمرو پیشنهاد شده است. یک روش آفلاین استفاده شده است که در آن AFTES  رکورد های نت فلو جمع آوری شده توسط روترها را آنالیز می کند، پیشوندهای آدرس منبع-مقصد را استخراج می کند، و از این پیشوندهای برای پیکربندی فیلترهای فایروال در روترهای ورودی شبکه یک ارائه دهنده استفاده می کند تا جریان های α آینده را به مسیرهای طراحی شده ترافیکی و صف های مجزا را دوباره هدایت می کند. سودمندی این طرح از طریق آنالیز هفت ماه از اطلاعات نت فلو بدست آمده از یک روتر شبکه علوم انرژی (Esnet)  ارزیابی شده بود.  درمورد این مجموعه اطلاعات، 91% از بایت های تولید شده توسط جریان های α در طول بازه های با سرعت بالا ممکن بود هدایت شوند اگر که AFTES بکارگرفته شده بود. همچنین، جنبه منفی استفاده پیشوندهای آدرس در فیلترهای فایروال، یعنی، هدایت دوباره جریان های β به صف ها / مسیرهای جریان α،بصورت کمی درآمده بودند .

1. مقدمه

            کاربردها محاسبه علمی در رشته های از قبیل فیزیک انرژی بابا، علم اقلیم، ژنومیک، و ...، مجموعه اصلاحات (با اندازه های ترا تا پتا بایت) حجیم تولید می کنند[1]. جهت انتقال این مجموعه های داده با سرعت های بالا، کاربرهای علمی اغلب در خوشه های محاسبه اعلاء با سری های دیسک، سیستم های فایل متقارن، و لینک های دسترسی با سرعت بالا خوشه های محاسبه اعلاء سرمایه گذاری می کنند. گزارش های استفاده که در این سرورهای انتقال داده جمع آوری شده اند، نشان می دهند که برخی از انتقال ها در یک کسر چشمگیر قابلیت لینک، یعنی، 4 Gbps برروی لینک های 10 Gbps اتفاق افتاده اند[2]. گونه های TCP جدید از قبیل H-TCP [3] جهت تولید چنین سرعت های بالایی برای جریان های واحد استفاده شده اند. انتقال های حجیم با سرعت بالا، که به آنها جریان های α گفته می شود، منبع اولیه نوسان در ترافیک IP می باشند[4]. 

            فراهم کننده های شبکه آموزش و تحقیق اصلی، از قبیل شبکه علوم انرژی (ESnet) سازمان انرژی US (DOE) [5]، تشخیص داده است که چنین جریان های α برای جریان های (β) با هدف کلی تاثیرات مضری دارد. از آنجایی که جریان های α باعث نوسان می شوند، برنامه های ویدو/صوت، واریانس تاخیر بسته (اختلال) و یک تحلیل مشابه در عمل تجربه می کنند. چنین زوال های در عمل باعث بلیط های مشکل ساز می شود که بر هزینه های اجرایی فراهم کننده می افزاید. به منظور رسیدگی به این هزینه ها، DOE تحقیقاتی برروی سیستم های مهندسی ترافیک را مورد حمایت قرار داده است. ما پیشنهاد می کنیم یک این چنین سیستمی: 1- جریان های انتقال داده حجیم با سرعت بالا را از ترافیک  بسته که به روترهای ورودی شبکه یک فراهم کننده وارد می شوند، مجزا می کند.2- مسیر استفاده شده توسط این جریان ها را بوسیله ایجاد مدارهای مجازی درون حوزه (مهندسی ترافیک) کنترل می کند. 3- بسته ها را از این جریان ها جدا می کند و در صف های مجازی مجزا قرار می دهد تا تاثیرات آنها برروی جریان های هدف کلی را کاهش دهد [6-8]. 

           اولین وظیفه سیستم مهندسی ترافیک که در بالا نام برده شد، یعنی شناسایی جریان های حجیم با سرعت بالا از ترافیک بسته که وارد شبکه فراهم کننده می شود، شرح مسئله است که در این تحقیق به آن پرداخته شده است.

           اساس رویکرد راه حل  ظاهرا یک راه حل ساده، این است که برنامه های کاربر نهایی از قبیل GridFTP [9] را اصلاح  می کند تا به شبکه فراهم کننده با یک پیام صفحه کنترل قبل از شروع هر انتقال حجیم با سرعت بالا علامت دهد. چنین پیامی می تواند نیاز به سیستم های شناسایی جریان α خودکار درون شبکه یک فراهم کننده را خنثی کند. این راه حل در پروژه های Lambdastation [10]، Terapaths [11]، و CHEETAH [12] مورد استفاده قرارگرفته بود، ولی مشکلات کاربردی ارتقاء ها و اقتباس برنامه بوسیله کاربران از بکارگیری آن جلوگیری می کرد. این مسئله باعث شد تا ما یک راه حل مهندسی ترافیک درون حوزه را دنبال کنیم زیرا بکارگیری این چنین سیستمی بطور کامل در کنترل فراهم کننده خواهد بود. چنین راه حلی از تلاش  برای اقتباس تکنولوژی همسان رویکرد علامت داده شده برنامه نهایی جلوگیری نمی کند. 

            برای شبکه های فراهم کننده جهت شناسایی خودکار جریان های α، ما با امتحان کردن ویژگی های دردسترس روترهای IP امروزی شروع می کنیم. متاسفانه، روترها مکانیزم های توکار جهت مشخص کردن اندازه و سرعت یک جریان را ندارند (جایی که یک "جریان" به وسیله توالی 5-tuple شناسایی شده است: آدرس های IP منبع و مقصد، شماره های درگاه لایه انتقال منبع و مقصد). در مرحله بعد، ما یک مکانیزم درگاه انعکاس دهنده را در نظر گرفتیم که در آن روترهای IP قابل پیکربندی بودند تا از بسته ها کپی بگیرد و آنها به یک درگاه  که به یک سرور بیرونی متصل است، انتقال دهد، و این عمل آخری سپس می تواند جهت اجرا کردن یک آنالیز اندازه/سرعت براساس جریان برای شناسایی جریان α مورد استفاده قرار گیرد. با این حال، چنین مکانیزمی برای سرعت های لینک بالا (10-100 Gbps) شبکه های فراهم کننده غیرقابل مقیاس پذیر تلقی می شود. 

              بعد از این نتیجه گیری که هیچ مکانیزم توکار برای محاسبه اندازه/سرعت جریان در درون روترها وجود ندارد، و اینکه درگاه منعکس کننده غیرممکن است، ما سعی کردیم مکانیزم های دیگری که قابل استفاده بودند را پیدا کنیم. یافته ما این است که نت فلو ، ویژگی که در روترهای IP مقیاس فراهم کننده حمایت شده است، برای حل مشکل ما قابل استفاده می باشد[13]. این ویژگی نت فلو به روترها چنین اجازه ای را می دهد تا اطلاعات را برای یک مجموعه نمونه گیری شده بسته ها جمع آوری کند، که سپس به شکل رکورد های نت فلو به یک جمع کننده نت فلو بیرونی انتقال می دهد. در راه اندازی های امروزی، رکوردهای نت فلو برروی یک دانه بندی زمان درشت (coarse time) که به ترتیب دقیقه به ساعت می باشد، انتقال داده می شود. یک آنالیز اطلاعات نت فلو نشان داد که پیش بینی دقیق بازه زمانی و اندازه یک جریان α بوسیله نظارت کردن تعداد کمی از اولین رکوردهای نت فلو مربوطه یک جریان (آنلاین) فعال امکان پذیر نیست. هر اقدام مهندسی ترافیک/ جداسازی جریان براساس این پیش فرض که یک جریان، جریان α  می باشد ممکن است بی ثمر باشد. زیرا جریان می تواند حتی قبل از اینکه اقدامات پیکربندی روتر برای مهندسی ترافیک و جداسازی جریان کامل شود، به پایان برسد. بنابراین، مکانیزم آفلاینی ایجاد کردیم که در آن رکورد های نت فلو از جریان های کامل شده مورد آنالیز قرارمی گیرند، و اطلاعات استخراج شده از این آنالیز برای پیکربندی روترها استفاده می شود تا جریان های α آینده برای مهندسی ترافیک و جداسازی جریان را شناسایی کند.

             رویکرد راه حل ما یک سیستم مدیریت شبکه با نام سیستم مهندسی ترافیک جریان آلفا (AFTES) را پیشنهاد کردیم که می تواند برروی یک سرور بیرون از روترها هم عمل کند. AFTES می تواند رکورد های نت فلو را از جمع کننده نت فلو جمع آوری کند و پیشوندهای آدرس منبع-مقصد جریان های α که از قبل تکمیل شده اند را ذخیره کند. این پیشوندها برای پیکربندی فیلترهای فایروال در ورودی روترها استفاده می شوند، تا جریان های α آینده بین زیرشبکه های منبع/مقصد مشابه به مسیرهای که براساس QoS کنترل شده و طراحی شده ترافیکی هدایت شوند. یک مقیاس مقاومت جهت حذف ورودی های پیشوند آدرس از فیلترهای فایروال که هیچ یک از جریان های α آنها در یک بازه رشد نظارت نشده اند، استفاده شده است. طرح AFTES درصورتی که فرضیه زیر درست باشد، مفید خواهد بود.

            فرضیه  اکثر شاخه های انتقال اطلاعات با سرعت بالا دارای آدرس های IP ثابت می باشند، و جریان های α بطور مکرر بین زیرشبکه های منبع-مقصد مشابه تولید می شوند. اساس این فرضیه این است که دانشمندان معمولا شبیه سازی هایشان را برروی مراکز ابرمحاسبه مشابه انجام می دهند، و به همین دلیل ما از آنها انتظار داریم که اطلاعات را بین دو خوشه مشابه انتقال دهند. درصورتی که این فرضیه درست باشد،  طرح AFTES مبتنی بر مشخص کننده پیشوند آفلاین در شناسایی و هدایت کردن جریان های α به مسیرهای که براساس QoS کنترل شده اند و طراحی شده ترافیکی ، موثر خواهد بود. ما آنالیز ترافیک رکورد های نت فلو جمع آوری شده از ESnet را انجام دادیم تا این فرضیه را آزمایش کنیم.

Abstract

             Large scientific data transfers often occur at high rates causing increased burstiness in Internet traffic. To limit the adverse effects of these high-rate largesized flows, which are referred to as a flows, on delay-sensitive audio/video flows, a network management system called Alpha Flow Traffic Engineering System (AFTES) is proposed for intra-domain traffic engineering. An offline approach is used in which AFTES analyzes NetFlow records collected by routers, extracts source–destination address prefixes of a flows, and uses these prefixes to configure firewall filters at ingress routers of a provider’s network to redirect future a flows to traffic-engineered paths and isolated queues. The effectiveness of this scheme was evaluated through an analysis of 7 months of NetFlow data obtained from an ESnet router. For this data set, 91 % of bytes generated by a flows during high-rate intervals would have been directed had AFTES been deployed. The negative aspect of using address prefixes in firewall filters, i.e., the redirection of b flows to a-flow paths/queues, was also quantified.

1 Introduction

            Scientific computing applications in fields such as high-energy physics, climate science, genomics, etc., generate large (tera- to peta-byte sized) data sets [1]. To transfer these data sets at high speeds, scientific users often invest in high-end computing clusters with disk arrays, parallel file systems, and high-speed access links. Usage logs collected at these data-transfer servers show that some transfers occurred at a significant fraction of link capacity, e.g., 4 Gbps1 on 10 Gbps links [2]. New TCP variants such as H-TCP [3] are used to generate such high rates for single flows. The high-rate large-sized transfers, referred to as a flows, are the primary source of burstiness in IP traffic [4].

             Core research-and-education network providers, such as US Department of Energy (DOE)’s Energy Sciences Network (ESnet) [5], have identified such a flows as having adverse effects on general-purpose (b) flows. As a flows cause burstiness, audio/video applications experience packet delay variance (jitter) and a corresponding degradation in performance. Such degradations in performance result in trouble tickets that add to a provider’s operational costs. To address these costs, DOE has supported research on traffic engineering systems. We propose one such system to (i) identify high-rate large-sized data-transfer flows from the packet traffic entering ingress routers of a provider’s network, (ii) control the path taken by these flows by establishing intra-domain virtual circuits (traffic engineering), and (iii) isolate packets from these flows into separate virtual queues to reduce their effects on general-purpose flows [6–8].

           The first task of the traffic-engineering system listed above, which is to identify high-rate large-sized flows from the packet traffic entering a provider’s network, is the problem statement addressed in this work.

           Basis for solution approach A seemingly simple solution is to modify end-user applications, such as GridFTP [9], to signal a provider’s network with a controlplane message before initiating any high-rate large-sized transfers. Such a message would negate the need for automatic a flow identification systems within a provider’s network. This solution was attempted in projects such as Lambdastation [10], Terapaths [11], and CHEETAH [12], but practical difficulties of application upgrades and adoption by users hindered its deployment. This led us to pursue an intra-domain traffic engineering solution because deployment of such a system would be entirely within a provider’s control. Such a solution does not preclude a parallel technology adoption effort of the end-application signaled approach.

           For provider networks to automatically identify a flows, we start by examining the available features in current-day IP routers. Unfortunately, routers do not have built-in mechanisms to determine the rate and size of a flow (where a ‘‘flow’’ is identified by the 5-tuple: source and destination IP addresses, source and destination transport-layer port numbers, and protocol type). Next, we considered a portmirroring mechanism in which IP routers could be configured to make and transmit copies of packets to a port that is connected to an external server; the latter could then be used to execute a flow-based rate/size analysis for a-flow identification. However such a mechanism was deemed unscalable for the high link rates (10–100 Gbps) of provider networks.

            After concluding that there are no built-in mechanisms for flow rate/size computation within routers, and that port-mirroring is infeasible, we looked for other mechanisms that could be exploited. Our finding is that NetFlow, a feature supported in provider-scale IP routers, can be used to solve our problem [13]. The NetFlow feature allows routers to collect information for a sampled set of packets, which is then exported, in the form of NetFlow records, to an external NetFlow Collector. In current-day installations, NetFlow records are exported on a coarse time granularity, which is on the order of minutes to hours. An analysis of the NetFlow data showed that it was not possible to accurately predict the duration and size of an a flow by observing the first few NetFlow records corresponding to a live (online) flow. Any traffic-engineering/flow isolation actions taken on the presumption of a flow being an a flow may be futile in that the flow could end even before the router-configuration actions for traffic-engineering/flow-isolation were completed. Therefore, we developed an offline mechanism in which NetFlow records from completed flows are analyzed, and information extracted from this analysis is used to configure routers to identify future a flows for traffic-engineering/flowisolation.

            Solution approach We propose a network management system called Alpha Flow Traffic Engineering System (AFTES) that would be run on a server external to the routers.2 AFTES would obtain NetFlow records from the NetFlow collector, and store the source–destination address prefixes of already completed a flows. These prefixes are used to configure firewall filters at ingress routers so that future a flows between the same source/destination subnets will get redirected to trafficengineered, QoS-controlled paths. A persistence measure is used to delete address prefix entries from the firewall filters for which no a flows are observed over an aging interval. This AFTES design would be effective if the following hypothesis is true.

          Hypothesis Most high-speed data transfer nodes have static IP addresses, and a flows are created repeatedly between the same source–destination subnets. The basis for this hypothesis is that scientists typically execute their simulations on the same supercomputing centers, and hence we expect them to transfer data between the same two clusters. If the hypothesis is true, the offline prefix identifier based AFTES scheme will be effective in identifying and directing a flows to traffic-engineered, QoS-controlled paths. We carried out traffic analysis of NetFlow records collected from ESnet to test this hypothesis.

چکیده
1. مقدمه
4. بررسی کلی
6. آنالیز اطلاعات نت فلو
6.2.2 سودمندی
7. خلاصه و نتیجه گیری ها
 منابع

Abstract
1 Introduction
4 AFTES Overview
6 NetFlow Data Analysis
6.2.2 Effectiveness
7 Summary and Conclusions
References