Please enable JavaScript.

Coggle requires JavaScript to display documents.

azure (storage (mechanizmy redundancji (Redundant Storage) (GRS (Global)…

- - - - 4.7TB max
      - poszczególne pliki
    - - stała wielkość (?)
      - max 8TB per plik
      - już się nie stosuje pod dyski, używa się managed disks
      - całe dyski VHD
    - - logi
      - składa się z bloków
      - max 195GB
      - można zwiększać
  - - - storage $$$, transfer 0
    - - storage $$, transfer $
    - - storage $, transfer $$
      - dostęp jest powolny - ~15h czekania
      - trzeba zmienić na hot lub cold by odczytać
  - - - 3x w regionie
    - - 3x w availability zone
    - - dyski w 3 regionach (każdy region dodatkowo LRS(?))
      - nie mamy wpływu na wybór regionów
    - - jak GRS - 3 regiony
      - można czytać z wszystkich nodów (GRZ, ZRS i LRS - praca tylko na masterze)
  - - - brak transakcyjności
- - - - czas alokacji zasobów per minuta
    - - wada- pada maszyna, dane tracone
      - szybkie
      - w tej samej fizycznej maszynie
    - - zmiana konfiguracji = restart
      - schedule
    - - azure virtual scale sets
        
        automatyczny loadbalancer
        
        klikane skalowanie
        
        automatyczne skalowanie
        
        różne reguły skalowania / formuły
        
        dodawanie/usuwanie VM w razie potrzeb
        
        dla VM które same w sobie są stateless
    - - dobre do DEV
      - wydajność dostępna przez jakiś czas
        
        np. 1h 1000% CPU
      - tanie
    - - kredyty
      - na jakiś czas
      - przenoszenie rezerwacji między maszynami
      - long term
    - - może być taniej
  - - - VNety w jednym regionie ale innychb subskrybcjach
        
        szybko
        
        tanio
  - - - bliżej = lepiej
  - - - azure public
        
        dla api publicznych / internetowych
      - azure priv
        
        pomiędzy VNEt'ami normalnie niewidocznymi publicznie
      - microsoft
- - - - github
      - jenkins
      - VS
      - ...
- - - - reprezentacja pojedynczej organizacji
    - - konto personalne
    - - konto dla usługi
  - - - lepsze zabezpieczenia
      - multifactor auth
  - - - kupują
      - dostają od organów ścigania
      - patrzą, czybuser AD nie jest w bazie która wyciekła
    - - niemożliwa podróz
      - nieznana lokacja
- - - - trzeba replikować ręcznie maszyny między zonami
      - każda maszyna --> $$$
- - - - grafowy
        
        gremlin api
      - data table
    - - strong
        
        spójny od rzu
        
        wolny
        
        drogi
        
        w jednym regionie
      - .....
      - eventual
        
        nie od razu spójny
        
        tani
        
        wiele regionów
      - session
        
        domyślny
      - ...
      - można przełączać w ramach zapytania
    - - coś ala "stored procedures"
      - procedure, trigger, funkcja
  - - - standard
      - podstawowa
      - premium
        
        tabele in memoy
        
        "30x faster"
        
        nie są ulotne
        
        ale tylko w modelu "hybrydowym"
      - premium RS
        
        jak premium, ale tańsza
        
        brak gwarantowanej dostępności
        
        do DEV raczej niż do PRD
    - - wskaźnik wydajności
      - CPU/pamięć/wydajność IO w porównaniu z OLTP
      - w praktyce nic nie mówi
      - trzeba sprawdzać w rzeczywistości
    - - domyślnie w 3 kopiach w regionie
      - mozna dodać ręczną replikację
        
        będzie też pod spodem w 3 nodach
        
        read-only (?)
        
        można między regionami
      - failover group
    - - jeden compute kilka baz
      - elastic - lepiej wykorzystuje zasoby zazwyczaj
      - microservices
    - - regiony sparowane
        
        szybki link między regionami
    - - auto-tuning
    - - point in time restore
        
        można cofnąć si e do dowolnego pkt w czasie
        
        uwaga: nie per transakcja, ale per czas
        
        restore = tworzenie nowej bazy ze starym stanem
      - 99,999% blabla
- - - - POD
        
        grupa kontenerów
        
        grupujemy, gdy współdzielone zasoby
        
        kontenery działają razem
        
        może im się zmieniać IP...
      - Service
        
        grupuje POD z adresem IP
        
        chowamy za loadbalancerem (?)
      - replication controller
        
        pilnuje ilości uruchomionych POD'ów
      - Deployments
        
        re-deploy pod'ów których definicja jest wymieniona w danym deploymencie
      - health management
        
        health checks
        
        poke po HTTP
      - secret management
        
        wrażliwe dane wstrzykiwane do kontenerów jako zmienne środowiskowe
- - - - można wtedy przenieść z R&D na PRD
- - - - standardowe SDK - odczyt zawsze oznaczony jako OK
      - pointer danych do odczytu
- - - - oddają kasę tylko za koszt samego azure
- - - - np. rozmpwnawanie czegokolwiek
      - np. rozpoznawanie twarzy
    - - analiza teeści / moderacja
      - czy obraźliwe, czy dla dorosłych, OCR