Spelling suggestions: "subject:"virtuella maskiner"" "subject:"ivirtuella maskiner""
1 |
Möjligheter att skapa en virtualiserad utvecklingsmiljö för WindowsNorfelt, Erik January 2007 (has links)
<p>Arbetet syftar till att undersöka förutsättningarna för att skapa en virtualiserad utvecklingsmiljö för Windows som installeras och konfigureras utan manuell övervakning. Utvecklare på Sandvik Systems Development (SSD) arbetar ofta med olika utvecklingsverktyg eller använder sig av olika versioner av utvecklingsmiljöer och detta är ett problem. Det är också vanligt att utvecklarna blandar sina kontorsapplikationer med utvecklingsmiljön vilket kan vara en stor säkerhetsrisk. Ett annat stort problem är att tiden kan vara väldigt lång för inhyrda konsulter och nyanställda att få sina utvecklingsmiljöer installerade, vilket resulterar i stora kostnader för SSD. En möjlig lösning till problemen är att använda virtuella maskiner som utvecklingsmiljöer. Arbetet undersöker om det är möjligt att m.h.a. en applikation skapa, installera och konfigurera virtuella maskiner och utvecklingsmiljöer automatiskt. Målmiljön för de virtuella maskinerna är programvarorna WMware Workstation och Virtual PC. Arbetet förklarar även hur virtuella maskiner kan vara till hjälp vid mjukvaruutveckling. Detta arbete visar att det är möjligt att skapa en virtualiserad utvecklingsmiljö som med vissa restriktioner installeras och konfigureras automatiskt.</p>
|
2 |
Möjligheter att skapa en virtualiserad utvecklingsmiljö för WindowsNorfelt, Erik January 2007 (has links)
Arbetet syftar till att undersöka förutsättningarna för att skapa en virtualiserad utvecklingsmiljö för Windows som installeras och konfigureras utan manuell övervakning. Utvecklare på Sandvik Systems Development (SSD) arbetar ofta med olika utvecklingsverktyg eller använder sig av olika versioner av utvecklingsmiljöer och detta är ett problem. Det är också vanligt att utvecklarna blandar sina kontorsapplikationer med utvecklingsmiljön vilket kan vara en stor säkerhetsrisk. Ett annat stort problem är att tiden kan vara väldigt lång för inhyrda konsulter och nyanställda att få sina utvecklingsmiljöer installerade, vilket resulterar i stora kostnader för SSD. En möjlig lösning till problemen är att använda virtuella maskiner som utvecklingsmiljöer. Arbetet undersöker om det är möjligt att m.h.a. en applikation skapa, installera och konfigurera virtuella maskiner och utvecklingsmiljöer automatiskt. Målmiljön för de virtuella maskinerna är programvarorna WMware Workstation och Virtual PC. Arbetet förklarar även hur virtuella maskiner kan vara till hjälp vid mjukvaruutveckling. Detta arbete visar att det är möjligt att skapa en virtualiserad utvecklingsmiljö som med vissa restriktioner installeras och konfigureras automatiskt.
|
3 |
Container overhead in microservice systems / Container overhead i microservice-systemFriðriksson, Vilhelm January 2018 (has links)
Containers have been gaining popularity in recent years due to their ability to provide higher flexibility, higher reliability and dynamic scalability to enterprise software systems. In order to fully utilize containers, software developers aim to build their software using microservice architecture, meaning that instead of working on a single large codebase for the whole project, the software is split into smaller units. These microservices can be deployed in their own container instead of the traditional virtual machine setup where a server has to configured with all necessary dependencies. Moving away from the monolithic software architecture to containerized microservices is bound to bring performance penalties due to increased network calls between services and container overhead. The integration must therefor be carefully planned in order to fully utilize the container setup while minimizing the overhead. The purpose of this thesis project was to measure how much overhead can be expected due to containers in an enterprise environment. By using a combination of virtual machines and Docker containers, a microservice system was deployed with four different deployment strategies and the system’s performance was measured by analyzing request response times under various loads. The services were made to run on a single server and on multiple servers, with and without Docker. The performance measurements showed that the system performed worse in every case when Docker was used. Furthermore, the results showed that Docker can have significant negative impact on performance when there is a heavy load on the system. / Containers har blivit populärare under de senaste åren tack vare deras förmåga att ge högre flexibilitet, högre tillförlitlighet och dynamisk skalbarhet för företagsprogramvarusystem. För att fullt ut kunna använda containers har programutvecklarna för avsikt att bygga sin programvara med hjälp av mikroservicearkitekturen, vilket innebär att programvaran delas upp i mindre enheter istället för att arbeta på en enda stor kodbas för hela projektet. Dessa mikroservices kan distribueras i sina egna containers istället för den traditionella virtuella maskininstallationen, där en server måste konfigureras med alla nödvändiga beroenden. Att flytta sig från monolitisk mjukvaruarkitektur till containeriserade microservices kommer att få prestandaförsämringar på grund av ökade nätverksanrop mellan tjänster och container-overhead. Integrationen måste därför noggrant planeras för att fullt ut utnyttja containeruppsättningen och minimera overhead. Syftet med detta avhandlingsprojekt var att mäta hur mycket overhead kan förväntas på grund av containers i en företagsmiljö. Genom att använda en kombination av virtuella maskiner och Dockercontainers, implementerades ett microservices-system med fyra olika implementeringsstrategier och systemets prestanda mättes genom att analysera anropens svarstid under olika belastningar. Tjänsterna gjordes för att köras på en enda server och på flera servrar, med och utan Docker. Prestandamätningarna visade att systemet var sämre i alla fall när Docker användes. Dessutom, visade resultaten att Docker kan ha signifikant negativ inverkan på prestanda när det är tung belastning på systemet.
|
4 |
Cloud Computing Security: A Systematic Literature ReviewBacke, Anton, Lindén, Hugo January 2015 (has links)
This literature review seeks to identify the major security issues and their solutions in cloud computing security as well as identifying areas for future research. Utilising a modified version of the approach suggested by Okoli and Schabram (2010) 52 articles were considered for the review, of which 26 were included in the final product. Although many security issues and solutions were identified it has become apparent that much of the research being done only relates to the theoretical side. Thus this review shows that while plenty of issues have been identified future research should focus more on the practical implications of these security risks. / Denna litteraturundersökning identifierar de huvudsakliga säkerhetsbristerna och de lösningar som åtfinns inom litteraturen om datormolnsäkerhet. Undersökningen använder sig av en modifierad version av metoden för litteraturundersökningar som skrivits av Okoli och Schabram (2010). Efter en första litteratursökning identifierades 52 artiklar som relevanta för undersökningen, av dessa 52 användes 26 i slutprodukten. Trots att flera olika säkerhetsbrister och lösningar för dessa identifierades var det uppenbart att mycket av forskningen enbart har teoretiska svar på bristerna. Undersökningen visar således att även om många hot har upptäckts av forskare saknas det forskning av de praktiska konsekvenserna av dessa brister.
|
5 |
Design of IP Multimedia Subsystem for Educational PurposesRudholm, Mikael January 2015 (has links)
Internet Protocol multimedia subsystem (IMS) is an architecture for services such as voice over Internet Protocol (VoIP) in IP based communication systems. IMS is standardized by the 3GPP standardization forum, and was first released in 2002. Since then IMS has not had the wide adoption by operators as first anticipated. As 3G already supported voice and video, the operators could not justify the expense of IMS. The current emergence of the fourth generation mobile communication system named Long Term Evolution (LTE) has, however, increased the need for knowledge of IMS and of creating services for it. LTE networks are IP only networks that provide low latency. In order to use LTE for making phone calls, VoIP technologies are needed. IMS is the architecture intended to be used for Voice over LTE (VoLTE). The need for tools for education within IMS was seen in 2006 by Enea Experts in Linköping, Sweden. The author of this thesis designed an IMS for educational purposes, but the project was never fully completed. This thesis will reexamine the design decisions previously made by the author. The requirements stated by the customer remain: that an IMS with basic signaling and logging should be easy to install, maintain, and evolve at a low cost. A literature study of IMS and VoLTE is presented to contribute with knowledge in these areas. The previous design and implementation made by the author is presented and analyzed. The third-party software that the previous implementation was based on is reexamined. Existing open source components are analyzed in order to identify how they can be used to solve the problem and to identify what remains to be developed in order to fulfill the requirements. New design suggestions, presented in today´s context, are proposed and verified using analytical reasoning and experiments. The outcome of the final work is new verified design decisions for the customer to use when implementing a new IMS for educational purposes. The thesis should also provide useful insights which instructors and students can use to teach and learn more about IMS. / Internet Protocol multimedia subsystem (IMS) är en arkitektur för tjänster, som IP-telefoni (Voice over Internet Protocol, VoIP), i IP baserade kommunikationssystem. IMS standardi¬seras av standardiseringsforumet 3GPP och första utgåvan släpptes år 2002. IMS fick dock inte det breda genomslag bland operatörer som förväntats. Eftersom 3G redan hade stöd för tal och video kunde operatörerna inte se skäl till ytterligare utgifter för IMS. Den fjärde generationens mobila kommunikationssystem, Long Term Evolution (LTE) är helt IP-baserat och ger lägre fördröjningar i nätet. För att kunna ringa telefonsamtal via LTE krävs VoIP-teknik. IMS är en arkitektur avsedd för att användas för Voice over LTE (VoLTE). Den nuvarande utvecklingen av LTE har därför ökat behovet av kunskap om IMS och av utveckling av IMS-tjänster. Enea Experts i Linköping insåg behovet av verktyg för utbildning inom IMS år 2006. Författaren av det här examensarbetet designade därför ett IMS för utbildningssyfte. Projektet slutfördes dock aldrig. Syftet med examensarbetet är att ompröva de tidigare designbesluten. Kundens krav kvarstår: att ett IMS med grundläggande signalering och loggning bör vara enkelt att installera, enkelt att underhålla och möjligt att utveckla till en låg kostnad. Arbetet innehåller en litteraturstudie av IMS och VoLTE för att ge en inblick i dessa områden. Den tidigare designen och implementationen presenteras och analyseras. Tredjeparts mjukvara, som den tidigare implementationen baserades på, omprövas. Befintliga programvaror med öppen källkod analyseras i syfte att kartlägga hur de kan användas för att lösa uppgiften, samt att identifiera vad som återstår att utveckla för att uppfylla kraven. Nya beslut kring design presenteras och besluten verifieras med experiment och analytiskt resonemang. Resultatet av detta examensarbete innefattar nya verifierade beslut kring design som kunden kan använda vid utveckling av ett nytt IMS för utbildningssyfte. Arbetet erbjuder också värdefulla insikter som instruktörer och elever kan använda för att undervisa samt för att lära sig mer om IMS.
|
6 |
Improving Software Deployment and Maintenance : Case study: Container vs. Virtual Machine / Förbättring av utplacering och underhåll av mjukvara : Fallstudie: Containers vs. Virtuella maskinerFalkman, Oscar, Thorén, Moa January 2018 (has links)
Setting up one's software environment and ensuring that all dependencies and settings are the same across the board when deploying an application, can nowadays be a time consuming and frustrating experience. To solve this, the industry has come up with an alternative deployment environment called software containers, or simply containers. These are supposed to help with eliminating the current troubles with virtual machines to create a more streamlined deployment experience.The aim of this study was to compare this deployment technique, containers, against the currently most popular method, virtual machines. This was done using a case study where an already developed application was migrated to a container and deployed online using a cloud provider’s services. Then the application could be deployed via the same cloud service but onto a virtual machine directly, enabling a comparison of the two techniques. During these processes, information was gathered concerning the usability of the two environments. To gain a broader perspective regarding the usability, an interview was conducted as well. Resulting in more well-founded conclusions. The conclusion is that containers are more efficient regarding the use of resources. This could improve the service provided to the customers by improving the quality of the service through more reliable uptimes and speed of service. However, containers also grant more freedom and transfers most of the responsibility over to the developers. This is not always a benefit in larger companies, where regulations must be followed, where a certain level of control over development processes is necessary and where quality control is very important. Further research could be done to see whether containers can be adapted to another company’s current environment. Moreover, how different cloud provider’s services differ. / Att sätta upp och konfigurera sin utvecklingsmiljö, samt att försäkra sig om att alla beroenden och inställningar är lika överallt när man distribuerar en applikation, kan numera vara en tidskrävande och frustrerande process. För att förbättra detta, har industrin utvecklat en alternativ distributionsmiljö som man kallar “software containers” eller helt enkelt “containers”. Dessa är ämnade att eliminera de nuvarande problemen med virtuella maskiner och skapa en mer strömlinjeformad distributionsupplevlese. Målet med denna studie var att jämföra denna nya distributionsteknik, containrar, med den mest använda tekniken i dagsläget, virtuella maskiner. Detta genomfördes med hjälp av en fallstudie, där en redan färdigutvecklad applikation migrerades till en container, och sedan distribuerades publikt genom en molnbaserad tjänst. Applikationen kunde sedan distribueras via samma molnbaserade tjänst men på en virtuell maskin istället, vilket möjliggjorde en jämförelse av de båda teknikerna. Under denna process, samlades även information in kring användbarheten av de båda teknikerna. För att få ett mer nyanserat perspektiv vad gäller användbarheten, så hölls även en intervju, vilket resulterade i något mer välgrundade slutsatser. Slutsatsen som nåddes var att containrar är mer effektiva resursmässigt. Detta kan förbättra den tjänst som erbjuds kunder genom att förbättra kvalitén på tjänsten genom pålitliga upp-tider och hastigheten av tjänsten. Däremot innebär en kontainerlösning att mer frihet, och därmed även mer ansvar, förflyttas till utvecklarna. Detta är inte alltid en fördel i större företag, där regler och begränsningar måste följas, en viss kontroll över utvecklingsprocesser är nödvändig och där det ofta är mycket viktigt med strikta kvalitetskontroller. Vidare forskning kan utföras för att undersöka huruvida containers kan anpassas till ett företags nuvarande utvecklingsmiljö. Olika molntjänster för distribuering av applikationer, samt skillnaderna mellan dessa, är också ett område där vidare undersökning kan bedrivas.
|
7 |
Improving Software Development Environment : Docker vs Virtual MachinesErlandsson, Rickard, Hedrén, Eric January 2017 (has links)
The choice of development environment can be crucial when it comes to developing a software. Few researches exist on comparing development environments. Docker is a relatively new software for handling and setting up container-environments. In this research, the possibility of using Docker as a software development environment is being investigated and compared against virtual machines as a development environment. The purpose of this research is to examine how the choice of development environment affect the development process. The work was qualitative, with an inductive and a deductive approach. It included a case study with two phases. One in which virtual machines and one in which Docker were used to implement a development environment. Observations were made after each implementation. The data from each implementation were then compared and evaluated against each other. The results from the comparisons and the evaluation clearly shows that the choice of development environment can influence the process of developing software. Different development environments affect the development process differently, both good and bad. With Docker, it’s possible to run more environments at once than when using virtual machines. Also, Docker stores the environments in a clever way that results in the environments taking up less space on the secondary storage compared to virtual machine environments. This is due to that Docker uses a layer system when it comes to containers and their components. When using Docker, no Graphical User Interface (GUI) to install and manage applications inside a container is provided, this can be a drawback since some developers may need a GUI to work. The lack of a GUI makes it harder to get an Integrated Development Environment (IDE) to work properly with a container to for example debug code. / Valet av utvecklingsmiljö kan vara avgörande vid utveckling av mjukvara. Få undersökningar finns idag angående jämförelser mellan utvecklingsmiljöer. Docker är en relativt ny mjukvara för att sätta upp samt hantera container- miljöer. I denna undersökning, kommer möjligheten att använda Docker som utvecklingsmiljö att undersökas och jämföras mot virtuella maskiner som utvecklingsmiljö. Syftet med undersökningen är att se hur valet av utvecklingsmiljö påverkar utvecklingsprocessen av en mjukvara. Arbetet bedrevs på ett kvalitativt sätt, med både ett induktivt samt ett deduktivt tillvägagångssätt. Det inkluderade även en fältstudie med två faser. En där virtuella maskiner och en där Docker användes till att implementera en utvecklingsmiljö. Observationer utfördes efter varje implementation. Data från varje implementation jämfördes och evaluerades mot varandra. Resultaten från jämförelserna och evalueringen visar att valet av utvecklingsmiljö har inflytande på processen av utveckling av mjukvara. Olika utvecklingsmiljöer påverkar utvecklingsprocessen olika, både på bra och dåliga sätt. Med Docker är det möjligt att köra fler miljöer samtidigt än vad som är möjligt vid användande av virtuella maskiner. Docker lagrar även miljöerna på ett smart sätt, som gör att de tar upp mindre plats på den sekundära lagringen jämfört med virtuella maskiner. Detta är på grund av att Docker använder sig av ett lager-system när det gäller containrar och deras komponenter. När Docker används, tillhandhålls inget Graphical User Interface (GUI) för att installera eller hanterar applikationer inuti en container, detta kan vara en nackdel då vissa utvecklare kan behöva ett GUI för att arbeta. Avsaknaden av ett GUI gör det svårare att få en Integrated Development Environment (IDE) att fungera ordentligt med en container för att till exempel avlusa kod.
|
8 |
Comparing Cloud Architectures in terms of Performance and ScalabilityJääskeläinen, Perttu January 2019 (has links)
Cloud Computing is becoming increasingly popular, with large amounts of corporations revenue coming in from various cloud solutions offered to customers. When it comes to choosing a solution, multiple options exist for the same problem from many competitors. This report focuses on the ones offered by Microsoft in their Azure platform, and compares the architectures in terms of performance and scalability.In order to determine the most suitable architecture, three offered by Azure are considered: Cloud Services (CS), Service Fabric Mesh (SFM) and Virtual Machines (VM). By developing and deploying a REST Web API to each service and performing a load test, average response times in milliseconds are measured and compared. To determine scalability, the point at which each service starts timing out requests is identified. The services are tested both by scaling up, by increasing the power of a single instance of a machine, and by scaling out, if possible, by duplicating instances of machines running in parallel.The results show that VMs fall considerably behind both CS and SFM in both performance and scalability, for a regular use case. For low amounts of requests, all services perform about the same, but as soon as the requests increase, it is clear that both SFM and CS outperform VMs. In the end, CS comes ahead both in terms of scalability and performance.Further research may be done into other platforms which offer the same service solutions, such as Amazon Web Services (AWS) and Google Cloud, or other architectures within Azure. / Molntjänster blir alltmer populära i dagens industri, där stora mängder av företagens omsättning består av tjänster erbjudna i form av molnlösningar. När det kommer till att välja en lösning finns många för samma problem, där det är upp till kunden att välja vilken som passar bäst. Denna rapport fokuserar på tjänster erbjudna av Microsofts Azure plattform, i en jämförelse av arkitekturer som belastningstestas för att mäta prestanda och skalbarhet.För att avgöra vilken arkitektur som är optimalast mäts tre olika tjänster erbjudna i Azure: Cloud Services (CS), Service Fabric Mesh (SFM) och Virtual Machines (VM). Detta görs genom att utveckla och deploya ett REST Web API som är simulerat med användare, där prestanda mäts genom att ta medelresponstiden i millisekunder per anrop. För att avgöra skalbarhet identifieras en punkt där tjänsten inte längre klarar av antalet inkommande anrop och börjar returnera felkoder. Maskinerna för varje tjänst testas både genom att skala upp, genom att förstärka en maskin, men även genom att skala ut, där det skapas flera instanser av samma maskin.Resultatet visar att Virtual Machines hamnar betydligt efter både CS och SFM i både prestanda och skalbarhet för ett vanligt användarfall. För låga mängder anrop ligger samtliga tjänster väldigt lika, men så fort anropen börjar öka så märks det tydligt att SFM och CS presterar bättre än Virtual Machines. I slutändan ligger CS i framkant, både i form av prestanda och skalbarhet.Vidare undersökning kan göras för de olika plattformarna erbjudna av konkurrenter, så som Amazon Web Services (AWS) och Google Cloud, samt andra arkitekturer från Azure.
|
Page generated in 0.0551 seconds