Wyniki 1-4 spośród 4 dla zapytania: authorDesc:"Radosław Czaja"

Wydajność i funkcjonalność programowalnej ścieżki danych w platformie NFV DOI:10.15199/59.2018.12.2


  1. INTRODUCTION Shortly after the NFV architecture introduction there were a few technologies proposed that allowed to solve the problem of performance and scalability of software based datapaths. Standard approach of using Linux based bridge connections became insufficient as binding multiple interfaces using bridge was not stable enough to provide proper Quality of Service (QoS) [11]. Multiple vendors faced the same challenge of requirement for high performance software datapath. The first approach proposed as a remedy was software switching. The biggest disadvantage of it was lack of guaranteed performance, as software switching for multiple high speed small sized frame connections became problematic when given little hardware resource [13]. While software switching is easy to adapt and still great approach for non QoS dependent solutions, there was a niche in the area of high-performance software datapath solutions. Over the next years technologies of Data Plane Development Kit (DPDK) and Single Root I/O Virtualization (SR-IOV) were introduced, with both being software-based solutions working at the hardware level. Both ideas are based on excluding Network Interface Card (NIC) from the system (unbinding from kernel) and either do software processing of the packet before kernel (DPDK) or spliting unbinded physical interface into multiple virtual private ones (SR-IOV). Both of these technologies improved the performance significantly in terms of latency and throughput. After DPDK was released a concept of DPDK modified Open vSwitch (OVS) arrived, where OVS would work on interfaces unbound from the operating system and the packet processing on physical interfaces was handled by software instead of kernel. Throughout this paper the concept of software datapath in carrier grade enviroment will be introduced. Reader will have the opportunity to explore common datapath solutions in OVS, SR-IOV with addition of PCI Passthrough i[...]

KEYSTONE - JAKO PROCES AUTORYZACYJNY SYSTEMU OPENSTACK DOI:10.15199/59.2015.8-9.125


  Niniejszy artykuł ma na celu ukazanie funkcjonowania serwisu Keystone odpowiedzialnego za uwierzytelnianie użytkowników w architekturze OpenStack. Stanowi on front-end tego systemu, sprawując kontrolę nad dostępem do zasobów zapewnia scentralizowaną politykę bezpieczeństwa. Komunikacja z serwisem odbywa się na zasadzie klient-serwer, gdzie Keystone obsługuje żądania wysyłane do jego API, w zamian generując klucze dostępowe dla określonych użytkowników w systemie. W artykule przedstawiono testy funkcjonalne i wyniki badań wydajnościowych serwisu Keystone. 1. WSTĘP Ogromny postęp w przeciągu ostatnich 20 lat w dziedzinach związanych z sieciami i systemami przechowującymi dane zaowocował powstaniem struktur o wysokiej funkcjonalności tzw. chmur obliczeniowych. Są to rozwiązania, które przewyższyły swoimi możliwościami swoich poprzedników skupiających się na przechowywaniu danych w ramach serwera. Nowoczesne podejście, jakim są chmury, bazują na różnych modelach zwanych "jako usługa" (ang. aaS), oferując użytkownikom gotowe rozwiązania po stronie infrastruktury, które zapewnia dostawca. Takie systemy mogą składać się z elementów rozproszonych geograficznie po całym świecie. Fakt ten nie będzie miał wpływu na dostępność do zasobów, a w zależności od odległości pomiędzy elementami będzie zmieniała się jedynie wartość opóźnienia. Niniejsza praca prezentuje moduł odpowiedzialny za uwierzytelnianie jednej z takich chmur o nazwie Open- Stack - Keystone. System OpenStack [1], którego Keystone jest elementem, to rozwiązanie z dziedziny chmur obliczeniowych zdolne do przechowywania, przetwarzania oraz modyfikowania danych. Jest to projekt open source napisany w języku Python, który jest w pełni kompatybilny z głównymi dystrybucjami Linuxa, co umożliwia zbudowanie środowiska w łatwy i przyjazny sposób. Zarządzanie systemem odbywa się za pomocą interfejsu graficznego poprzez dostęp z poziomu przeglądarki internetowej lub za pomocą R[...]

USŁUGA RÓWNOWAŻENIA OBCIĄŻENIA W SYSTEMIE OPENSTACK LOAD BALANCING SERVICE IN OPENSTACK DOI:10.15199/59.2016.8-9.33


  Niniejszy artykuł ma na celu pokazanie funkcjonowania równoważenia obciążenia dla serwisu Neutron odpowiedzialnego za tworzenie i obsługę usług sieciowych dla użytkowników OpenStack’a. Stanowi on podstawę do zapewnienia komunikacji wewnątrz systemowej, z systemem jak i z wewnętrznymi prywatnymi sieciami systemowymi. W artykule przedstawiono wyniki bazując na edycji Juno, którą zaimplementowano w celu przeprowadzenia badań i analizy możliwości systemu pod kątem świadczenia usług sieciowych dla wirtualnych maszyn. Abstract: This paper aims to show the Load Balancing service for the Neutron networking service, which is responsible for the creation and maintenance of network services for users in OpenStack. It provides the basis for communication within the system, communications with the system and within internal networks. The paper investigates Juno release which was implemented in order to conduct the research and analysis of network capabilities to provide services to virtual machines. Słowa kluczowe: OpenStack, Równoważenie Obciążenia, Wirtualizacja Keywords: OpenStack, Load Balancing, Virtualization 1. WSTĘP Ogromny postęp w przeciągu ostatnich 20 lat w dziedzinach związanych z sieciami i systemami przechowującymi dane zaowocował powstaniem struktur o wysokiej funkcjonalności tzw. chmur obliczeniowych. Są to rozwiązania, które przewyższyły swoimi możliwościami swoich poprzedników skupiających się na przechowywaniu danych w ramach serwera czy świadczenia usług użytkownikom. Nowoczesne podejście, jakim są chmury, bazują na różnych modelach zwanych "jako usługa" (ang. as a service), oferując użytkownikom gotowe rozwiązania po stronie infrastruktury, które zapewnia dostawca. Takie systemy mogą składać się z elementów rozproszonych geograficznie po całym świecie. Fakt ten nie będzie miał wpływu na dostępność do zasobów, a w zależności od odległości pomiędzy elementami będzie zmieniała się jedynie wartość opóźnienia[...]

Wirtualizacja SD-WAN: praktyczna implementacja NFV DOI:10.15199/59.2018.12.3


  1. INTRODUCTION The telecommunication industry is experiencing pressure to match rapidly changing customer requirements and to reduce costs at the same time. Innovative operators are moving away from legacy network hardware towards datacenter micro-services to reduce both OPEX and CAPEX, and to decrease the service delivery time by making the process fully automatic [10]. Thanks to NFV (Network Functions Virtualization) [1], it is possible to get automated network deployment and administration as well as reduce the related cost. NFV offers a different approach to network operations, allowing various types of Virtual Network Functions (VNFs) to run on standard servers. Each virtual component can be a standalone function or a part of full-scale network, depending on the virtual service design. In order to minimize the amount of manual activities during network service creation and device enabling, the Zero Touch Provisioning (ZTP) concept was introduced which provides the ability to perform service turn-up without site-specific pre-configuration or manual intervention, over any kind of access network even wireless one e.g. Long Term Evolution (LTE). This document describes the use of NFV with one of the typical VNF applications: Software-Defined Wide Area Networks (SD-WAN) [3]. The document is organized as follows. Chapter 2 presents reference architecture according to ETSI and revises a few examples of virtual network functions [5]. Next discusses sample application based on a real business NFV use case. The chapter is also partially focused on the technical implementation of automatic configuration and management of network services. Fourth chapter focuses on SD-WAN network function deployment, and analysis of various aspects of service creation and VNF automation. Chapter 5 allows reader to go through a quick discussion that highlights main aspects of the topic. Last chapter provides a set of final conclusions. 2. REFERENC[...]

 Strona 1