Принстонська та Гарвардська архітектури МК. Загальна структура МК
Прінстонська архітектура, яка часто називається архітектурою Фон-Неймана, характеризується використанням загальної оперативної пам'яті для зберігання програм, даних, а також для організації стека. Для звернення до цієї пам'яті використовується загальна системна шина, по якій в процесор надходять і команди, і дані. Ця архітектура має ряд важливих переваг. Наявність загальної пам'яті дозволяє оперативно перерозподіляти її обсяг для зберігання окремих масивів команд, даних і реалізації стека в залежності від розв'язуваних завдань. Використання спільної шини для передачі команд і даних значно спрощує відладку, тестування і поточний контроль функціонування системи, збільшує її надійність. Тому Прінстонська архітектура протягом довгого часу домінувала в обчислювальній техніці.
Основний недолік - необхідність послідовної вибірки команд і даних по спільній системній шині. При цьому шина стає вузьким місцем, яке обмежує продуктивність системи. Постійно зростаючі вимоги до продуктивності мікропроцесорних систем викликали в останні роки більш широке застосування Гарвардської архітектури при створенні багатьох типів сучасних мікропроцесорів.
Гарвардська архітектура характеризується фізичним поділом пам'яті команд (програм) і пам'яті даних. У її оригінальному варіанті використовувався також окремий стек для зберігання вмісту програмного лічильника, який забезпечував можливості виконання вкладених підпрограм. Кожна пам'ять з'єднується з процесором окремої шиною, що дозволяє одночасно з читанням/записом даних при виконанні поточної команди робити вибірку і декодування наступної команди. Завдяки такому поділу потоків команд і даних і поєднанню операцій їх вибірки реалізується більш висока продуктивність, ніж при використанні Прінстонской архітектури.
Недоліки Гарвардської архітектури пов'язанні з необхідністю проведення більшого числа шин, а також з фіксованим об'ємом пам'яті, виділеної для команд і даних, призначення якої не може оперативно пеперозподілятися. Тому потрібно використовувати пам'ять більшого об'єму, коефіцієнт використання якої при вирішенні різноманітних задач виявляється нижчим, ніж в системах з Прінстонською архітектурою. Проте розвиток мікроелектроніки дозволив в значній мірі подолати вказані недоліки, тому Гарвардська архітектура широко застосовується у внутрішній структурі сучасних мікропроцесорів, де використовується окрема кеш-пам'ять для зберігання команд і даних. Разом з цим, у зовнішній структурі більшості мікропроцесорних систем реалізуються принципи Прінстонської архітектури.
Мікроконтролер є функціонально закінченою МПС, яка реалізована у вигляді однієї великої інтегральної мікросхеми. МК об'єднує в одному кристалі основні елементи МПС: центральний процесор (ЦП), постійне запам'ятовуючий пристрій (ПЗУ), оперативний запам'ятовуючий пристрій (ОЗП), порти вводу/виводу.
Структура мікроконтролера: ядро, регістри, пам'ять, кеш, загальний введення-виведення, таймери, переривання, watchdog, периферія,можливість налагодження.
Топологія підключення USB-пристроїв. Структура кадру
Топологія підключення USB-пристроїв може бути деревоподібною (tree topology) або лінійною (linear topology).
У деревоподібній топології, USB-хаб (hub) є центральним вузлом із портами для підключення USB-пристроїв. Кожен порт USB-хаба може бути використаний для підключення іншого USB-хаба або для підключення пристрою напряму. Ця топологія дозволяє підключати багато пристроїв до одного порту комп'ютера.
У лінійній топології, USB-пристрої підключаються один за одним до портів комп'ютера або USB-хаба в лінію. Ця топологія підходить для підключення небагатьох пристроїв.
Структура кадру USB складається з чотирьох частин: преамбула (preamble), заголовок (header), поле даних (data field) та контрольна сума (CRC). Преамбула включає сигнализацію про початок кадру, заголовок містить інформацію про тип та розмір кадру, поле даних містить самі дані, а контрольна сума використовується для перевірки правильності передачі даних. Кожен кадр містить адресу призначення та джерела, які використовуються для розрізнення пристроїв та управління передачею даних.
АД-202 Ворошилін Артем
Структура платформи vSphere
vSphere є віртуалізаційною платформою, що розроблена компанією VMware. Основним елементом структури платформи є гіпервізор ESXi, який дозволяє віртуалізувати фізичні сервери та створювати на них віртуальні машини. ESXi працює як операційна система на сервері та надає віртуальним машинам доступ до апаратних ресурсів сервера, таких як процесор, оперативна пам'ять та сховище.
Для керування гіпервізором та віртуальними машинами використовується програмне забезпечення vCenter Server. Воно забезпечує централізоване керування, моніторинг та управління ресурсами на кластері серверів, що працюють під управлінням ESXi.
Крім того, в платформі vSphere є такі елементи:
vSphere Web Client - це веб-інтерфейс для керування віртуальними машинами та ресурсами кластеру.
vSphere Client - це додаток для керування віртуальними машинами та ресурсами кластеру, який встановлюється на робочих станціях.
vSphere Update Manager - це інструмент для керування та оновлення пакетів оновлень для ESXi та віртуальних машин.
vSphere Distributed Switch - це розширена мережева комутаційна матриця, яка дозволяє створювати віртуальні мережі між віртуальними машинами та кластерами серверів.
vSphere High Availability - це функція, що забезпечує автоматичне відновлення віртуальних машин в разі збоїв у апаратному забезпеченні або програмному забезпеченні.
vSphere Fault Tolerance - це функція, що забезпечує безперервну роботу віртуальних машин, навіть якщо стане недоступним один з серверів.
vSphere Storage vMotion - це функція, яка дозволяє переміщувати віртуальні машини між різними сховищами даних без відключення їх від мережі.
vSphere Storage DRS - це функція, яка автоматично керує розподілом даних між сховищами даних, що дозволяє ефективно використовувати ресурси сховища та забезпечує високу доступність даних.
vSphere Replication - це функція, яка забезпечує резервне копіювання віртуальних машин та їх відновлення в разі відмови обладнання або програмного забезпечення.
vSphere vRealize Operations Manager - це інструмент для моніторингу та аналізу ресурсів кластеру, що дозволяє відстежувати продуктивність віртуальних машин та ресурсів кластеру, прогнозувати навантаження та вирішувати проблеми.
Ці елементи платформи vSphere дозволяють керувати та управляти ресурсами віртуальних машин та забезпечують високу доступність, надійність та продуктивність інфраструктури.
Вимоги до архітектури ЕОМ для підтримки віртуалізації
Архітектура комп'ютерної системи повинна мати певні характеристики для підтримки віртуалізації. Ось деякі з основних вимог:
1. Підтримка апаратної віртуалізації: Комп'ютер повинен мати підтримку апаратної віртуалізації, яка дозволяє створювати і управляти віртуальними машинами без додаткових рівнів абстракції від апаратного забезпечення.
2. Ресурсні вимоги: Віртуальні машини вимагають значних ресурсів, включаючи процесорний час, пам'ять та ввід/вивід. Архітектура повинна бути достатньо потужною, щоб забезпечити необхідні ресурси для запуску віртуальних машин.
3. Масштабованість: Комп'ютер повинен мати можливість масштабування для забезпечення необхідної продуктивності під час запуску декількох віртуальних машин на ньому.
4. Безпека: Віртуалізація повинна бути безпечною, щоб запобігти несанкціонованому доступу до віртуальних машин та забезпечити ізоляцію між ними.
5. Управління ресурсами: Архітектура повинна забезпечувати ефективне управління ресурсами для віртуальних машин, зокрема процесорним часом, пам'яттю та ввід/вивідом.
6. Підтримка мережевої віртуалізації: Архітектура повинна підтримувати мережеву віртуалізацію, щоб забезпечити доступ віртуальних машин до мережі та ізоляцію між ними.
7. Легка підтримка: Архітектура повинна бути легкою у підтримці та налагодженні.
8. Підтримка різних операційних систем: Архітектура повинна підтримувати запуск різних операційних систем у віртуальних машинах, зокрема, Windows, Linux та інших.
9. Низький рівень латентності: Віртуальні машини повинні працювати з низькою латентністю, щоб забезпечити ефективну роботу віртуальних середовищ.
10. Підтримка віртуалізації на різних рівнях: Архітектура повинна підтримувати віртуалізацію на різних рівнях, включаючи апаратну, програмну та контейнеризацію.
11. Підтримка міграції віртуальних машин: Архітектура повинна підтримувати міграцію віртуальних машин з одного фізичного сервера на інший без втрати продуктивності.
12. Підтримка балансування навантаження: Архітектура повинна підтримувати балансування навантаження між різними віртуальними машинами на комп'ютері.
13. Підтримка резервування ресурсів: Архітектура повинна підтримувати резервування ресурсів для віртуальних машин, щоб забезпечити стійкість роботи у випадку збою в апаратному забезпеченні.
14. Підтримка віддаленого управління: Архітектура повинна підтримувати віддалене управління віртуальними машинами, щоб забезпечити їх ефективне керування з різних пристроїв та місць.
Ці вимоги є необхідними для створення ефективної та стійкої архітектури ЕОМ для підтримки віртуалізації.