WEBVTT

00:00.000 --> 00:02.190
Instruktor: Wirtualizacja jest ważna dla bezpieczeństwa

00:02.190 --> 00:05.010
zarówno naszych serwerów lokalnych, jak i serwerów w chmurze.

00:05.010 --> 00:06.630
W ostatnich latach wirtualizacja

00:06.630 --> 00:08.280
nadal się rozwija, pomagając zmniejszyć

00:08.280 --> 00:10.410
zapotrzebowanie na dodatkowe zasilanie, przestrzeń

00:10.410 --> 00:12.570
i chłodzenie naszych serwerowni oraz zmniejszając

00:12.570 --> 00:15.120
fizyczną architekturę związaną ze wspieraniem naszych

00:15.120 --> 00:17.850
operacji informatycznych.

00:17.850 --> 00:19.950
Czym jest wirtualizacja?

00:19.950 --> 00:22.230
Wirtualizacja to komputer-host z zainstalowanym

00:22.230 --> 00:23.910
hiperwizorem, który może być używany

00:23.910 --> 00:25.110
do instalowania i zarządzania

00:25.110 --> 00:27.210
wieloma systemami operacyjnymi gościa lub maszynami

00:27.210 --> 00:30.270
wirtualnymi, znanymi jako maszyny wirtualne.

00:30.270 --> 00:31.950
Jak to wygląda?

00:31.950 --> 00:34.260
Cóż, zasadniczo masz kawałek sprzętu, który

00:34.260 --> 00:36.600
nazywa się bare bones lub bare metal, a następnie

00:36.600 --> 00:39.360
instalujesz na nim jakieś oprogramowanie do wirtualizacji,

00:39.360 --> 00:42.540
które będzie znane jako hypervisor.

00:42.540 --> 00:45.420
Obecnie hiperwizor występuje w dwóch rodzajach.

00:45.420 --> 00:48.270
Możesz mieć hiperwizor bare bones lub bare metal,

00:48.270 --> 00:50.610
który działa natywnie na sprzęcie lub możesz

00:50.610 --> 00:52.650
mieć system operacyjny z hiperwizorem

00:52.650 --> 00:55.680
działającym na tym systemie operacyjnym i to jest nasz

00:55.680 --> 00:57.510
drugi typ.

00:57.510 --> 01:01.320
Na przykład na moim laptopie mam MacBooka Pro, a na

01:01.320 --> 01:04.950
tym MacBooku Pro mam system operacyjny Mac.

01:04.950 --> 01:06.720
W tym systemie operacyjnym Mac zainstalowałem

01:06.720 --> 01:09.480
hiperwizor znany jako VMware, na którym mogę faktycznie

01:09.480 --> 01:10.980
uruchamiać system Windows wewnątrz

01:10.980 --> 01:14.580
maszyny wirtualnej na moim komputerze Mac.

01:14.580 --> 01:17.190
Teraz, w ramach wirtualizacji hiperwizora, mogę

01:17.190 --> 01:19.530
zainstalować system operacyjny gościa,

01:19.530 --> 01:22.800
w moim przypadku Windows, i dodać dowolne aplikacje.

01:22.800 --> 01:25.170
Tak więc na moim konkretnym systemie Mac,

01:25.170 --> 01:27.630
mimo że używam Maca jako mojego systemu operacyjnego

01:27.630 --> 01:29.340
jako systemu operacyjnego hosta,

01:29.340 --> 01:32.160
mam maszynę wirtualną z systemem Windows 10 i drugą

01:32.160 --> 01:34.590
z systemem Ubuntu Linux.

01:34.590 --> 01:37.710
Mam jeszcze jeden, na którym działa Kali Linux i podobne rzeczy.

01:37.710 --> 01:40.650
W ten sposób mam dostęp do wszystkich tych systemów operacyjnych dla

01:40.650 --> 01:42.090
dowolnych programów, których potrzebuję

01:42.090 --> 01:45.300
lub demonstracji, które próbuję przeprowadzić w moich kursach.

01:45.300 --> 01:47.520
Tak więc, gdy używamy wirtualizacji, każdy

01:47.520 --> 01:50.880
serwer lub host będzie uruchamiał swój własny system operacyjny

01:50.880 --> 01:52.950
wewnątrz tej maszyny wirtualnej, ale

01:52.950 --> 01:56.850
maszyny wirtualne są uruchamiane na hiperwizorze.

01:56.850 --> 01:59.460
Hiperwizor służy do zarządzania dystrybucją

01:59.460 --> 02:02.280
zasobów fizycznych serwera lub hosta do tych maszyn

02:02.280 --> 02:03.780
wirtualnych, w tym ilością

02:03.780 --> 02:06.030
przetwarzania, pamięci i miejsca na dysku

02:06.030 --> 02:08.850
twardym, które każda z nich otrzyma.

02:08.850 --> 02:11.100
Jak już wspomniałem, hiperwizory występują

02:11.100 --> 02:13.290
w dwóch różnych typach lub smakach.

02:13.290 --> 02:15.780
Nazywamy je typem pierwszym i typem drugim.

02:15.780 --> 02:18.690
Hiperwizor typu pierwszego jest również znany jako bare

02:18.690 --> 02:20.910
metal, ponieważ działa bezpośrednio na sprzęcie

02:20.910 --> 02:23.580
hosta i działa jako sam system operacyjny.

02:23.580 --> 02:26.130
Przykładami mogą być Hyper-V,

02:26.130 --> 02:29.160
XenServer, ESXi i vSphere.

02:29.160 --> 02:31.530
Wszystko to są hiperwizory typu pierwszego.

02:31.530 --> 02:34.200
Teraz dwa hiperwizory działają z poziomu zwykłego

02:34.200 --> 02:35.520
systemu operacyjnego.

02:35.520 --> 02:39.000
Coś takiego jak Windows, macOS X lub Linux.

02:39.000 --> 02:41.520
Na przykład, jeśli używamy VMware Workstation

02:41.520 --> 02:44.490
lub VirtualBox wewnątrz pulpitu Windows 10, jest

02:44.490 --> 02:47.280
to uważane za hiperwizor typu drugiego.

02:47.280 --> 02:49.830
W przypadku hiperwizora typu pierwszego lub drugiego nadal

02:49.830 --> 02:52.140
musimy upewnić się, że każda maszyna wirtualna uruchamia

02:52.140 --> 02:54.240
własną kopię systemu operacyjnego.

02:54.240 --> 02:58.050
Coś takiego jak Red Hat Linux lub Windows Server 2019.

02:58.050 --> 03:00.510
Wszystkie te serwery wymagają takich samych aktualizacji,

03:00.510 --> 03:02.490
łatek bezpieczeństwa i poprawek, jak

03:02.490 --> 03:04.290
tradycyjny serwer, więc musimy śledzić

03:04.290 --> 03:06.780
każdą z tych maszyn wirtualnych i upewnić się, że

03:06.780 --> 03:10.530
ich stan bezpieczeństwa jest dobrze dostrojony.

03:10.530 --> 03:13.020
Obecnie wykorzystanie wirtualizacji w całej

03:13.020 --> 03:15.090
branży wzrosło wykładniczo.

03:15.090 --> 03:17.490
Wirtualizacja rozpoczęła się od wirtualizacji serwerów,

03:17.490 --> 03:20.670
a teraz rozszerzyła się również na dostarczanie aplikacji użytkownikom

03:20.670 --> 03:22.590
z centralnej lokalizacji.

03:22.590 --> 03:24.180
Istnieją tak naprawdę dwa modele dostarczania

03:24.180 --> 03:26.490
zwirtualizowanych usług aplikacji.

03:26.490 --> 03:29.190
Są one znane jako wirtualizacja aplikacji oparta na serwerze

03:29.190 --> 03:30.540
lub usługach terminalowych oraz

03:30.540 --> 03:32.820
wirtualizacja aplikacji oparta na kliencie, znana

03:32.820 --> 03:34.710
jako strumieniowanie aplikacji.

03:34.710 --> 03:36.000
Obecnie usługi terminalowe

03:36.000 --> 03:38.310
to oparte na serwerze rozwiązanie wirtualizacyjne,

03:38.310 --> 03:40.110
które uruchamia aplikację na serwerach

03:40.110 --> 03:41.550
w scentralizowanej lokalizacji,

03:41.550 --> 03:43.560
a użytkownicy uzyskują dostęp do tej aplikacji

03:43.560 --> 03:45.060
za pośrednictwem protokołu zdalnego

03:45.060 --> 03:48.630
klienta, takiego jak RDP firmy Microsoft lub ICA firmy Citrix.

03:48.630 --> 03:51.240
Przykładami takich rozwiązań są Microsoft Terminal

03:51.240 --> 03:52.980
Services i Citrix XenApp.

03:52.980 --> 03:54.570
Z drugiej strony, strumieniowanie aplikacji

03:54.570 --> 03:56.850
jest rozwiązaniem wirtualizacyjnym opartym na kliencie, które

03:56.850 --> 03:58.890
umożliwia pakowanie aplikacji i przesyłanie ich strumieniowo

03:58.890 --> 04:01.260
bezpośrednio do komputera użytkownika.

04:01.260 --> 04:04.170
Tworzy to środowisko obliczeniowe aplikacji typu sandbox, które jest

04:04.170 --> 04:06.540
odizolowane od systemu operacyjnego użytkownika.

04:06.540 --> 04:10.170
App-V firmy Microsoft jest doskonałym przykładem tej technologii.

04:10.170 --> 04:12.240
Zaletą korzystania z usług terminalowych

04:12.240 --> 04:13.620
lub strumieniowania aplikacji

04:13.620 --> 04:14.850
jest to, że możemy wymusić

04:14.850 --> 04:16.860
na nich dodatkowe zabezpieczenia.

04:16.860 --> 04:19.560
Rzeczy takie jak szyfrowanie, kontrola dostępu do serwera i zapobieganie

04:19.560 --> 04:21.480
przechowywaniu danych lokalnie na komputerze

04:21.480 --> 04:22.770
użytkownika końcowego w celu zapewnienia

04:22.770 --> 04:25.053
bezpieczeństwa tych danych.
