Технология облачных сред   к мультимедиа технологиям   Эволюция глобальной сети Интернет   технологии программирования

Облачные вычисления: обзор и рекомендации

Общая среда облачных вычислений (Раздел 4)

Рекомендации Национального Института Стандартов и Технологий (США)
Special Publication 800-146 (Draft)

В момент написания этого материала многие лица и организации изложили свою точку зрения относительно <концепции>  облачных вычислений (cloud computing), ее преимуществ и недостатков. Однако, необходимо понимать, что термин “облачные вычисления” охватывает большое многообразие как систем и технологий, так и моделей развертывания, <предоставления> услуг и ведения бизнеса. Ряд утверждений, которые иногда делаются относительно облачных вычислений, например, что они “масштабируются” или что они конвертируют капитальные затраты (CAPEX) в операционные (OPEX), являются верными только для определенных видов облачных систем. Цель этого раздела состоит в том, чтобы четко описать разделение систем облачных вычислений или облачных систем на пять значимых сценариев и, для каждого из этих сценариев, объяснить основные аспекты (такие, как масштабируемость), требующие внимания или вызывающие споры, и как эти аспекты адресуются в отношении каждого из сценариев (2).

2) Этот раздел представляет физический - сетевой взгляд на то, как подписчики (облачные потребители - заказчики) сервисов подключены к облачным системам. Понимание облачного и составных частей традиционного “стека” программного обеспечения, доступных для подписчиков является не менее важным и рассматривается в разделах 5, 6 и 7 этого (оригинального) документа.

Как это предполагается в определении облачных вычислений NIST, облачная система является коллекцией ресурсов, доступных по сети для заказчиков (т.е. облачных подписчиков – облачных потребителей). В общем случае, облачная система и ее подписчики применяют модель клиент-сервер, которая предполагает, что подписчики отправляют по сети сообщения серверным компьютерам, которые в ответ на полученные сообщения выполняют соответствующую работу.

Рисунок 1: Общий взгляд на облако и подписчиков

Рисунок 1 дает общий взгляд на облако и его клиентов: облачные вычислительные ресурсы описаны как комплекс взаимосвязанных* компьютерных систем, доступ к которым клиенты осуществляют по сети. Как показано на рисунке, могут появляться новые клиенты, старые клиенты могут уходить, в разные моменты времени количество клиентов будет разным. Подобным образом и облако поддерживает пул аппаратного обеспечения, которым управляет для максимизации (увеличения производительности и уровня) сервиса и минимизации издержек. Для поддержки высокой доступности сервисов, несмотря на ожидаемые отказы и истечение срока жизни компонент, облако мере возникновения необходимости** подключает новые и выводит из эксплуатации старые или отказавшие аппаратные компоненты. Облако эффективно управляет пулом аппаратных ресурсов для оптимального, с т.з. издержек, предоставления сервисов. Одна из стратегий <такого управления> состоит в том, что облачный провайдер отключает неиспользуемые компоненты на период сокращения потребностей подписчиков. С позиций ли управления потребляемой мощностью или обновления аппаратного обеспечения, миграция рабочих нагрузок (workloads) заказчиков с одного физического компьютера на другой является ключевой стратегией, позволяющей провайдеру обновлять аппаратное обеспечение и консолидировать рабочие нагрузки без причинения неудобств подписчикам.

*) в данном случае, grid представляется логичным перевести именно так, т.к. облачные вычисления не всегда предполагают использование Grid-технологий. Lingvo Computers даёт следующие определения:

В свою очередь, облачные технологии напрямую не подразумевают (хотя и не отрицают) использование распределения выполнения частей задачи по разным узлам “решетки”, представляющей собой распределенные вычислительные ресурсы, связанные особым образом для выполнения, фактически, массово-параллельных вычислений.

**) наверняка, вы обратили внимание, что в предлагаемых переводах “as needed” и “on demand” переводятся не “по требованию”, а “по необходимости”. Такой выбор обусловлен более мягким и, в определенной степени, превентивным для ряда случаев смыслом “по необходимости”. Требование потребителя, поступившее в той или иной форме, может не всегда соответствовать согласованному уровню сервиса (SLA), а необходимость может быть идентифицирована провайдером сервиса вообще без уведомления об этом клиента. Например, необходимость или потребность выявляется на основе анализа статистики использования пула ресурсов клиентами и прогноза на дальнейший рост утилизации ресурсов, связанный как с увеличением потребностей существующих клиентов в ресурсах, так и с увеличением числа клиентов (экстенсивное или количественное развитие) и/или расширением портфеля предоставляемых услуг того или иного типа (интенсивное или качественное развитие).

Рисунок 1 представляет лишь небольшую часть общих утверждений (соображений, аспектов), характерных для облачных вычислений . Организации предполагают, что использование  облачных вычислений должно отражать такие общие положения (представлены ниже). В то же время, многие из утверждений, сформулированные в отношении облачных вычислений (например, что облака могут масштабироваться для очень больших рабочих нагрузок или их применение позволяет заменять капитальные затраты операционными), являются корректными только для определенных типов облаков. Для избежания путаницы, этот документ явно квалифицирует каждое из таких положений для каждого типа облака, где такое положение применимо - т.е. каждое утверждение обладает границами <применимости> содержания (“scope”). Такие границы, используемые в документе, представлены в Таблице 1.

Таблица 1: Сценарии - варианты границ применимости утверждений, используемых в отношении облаков (Scope Modifiers for Statements Asserted About Clouds)

Границы применимости - сценарии

Описание границ применимости

общий случай,
т.е. все варианты облаков
(general)
Применяется для всех моделей развертывания облаков
собственное частное облако
(on-site-private)
Применяется к частным облакам, реализованным на площадке заказчика (т.е. полностью контролируемые заказчиком)
частное облако на аутсоурсинге
(oursourced-private)
Применяется к частным облакам, размещенным на внешнем хостинге, обслуживаемом аутсоурсинговой компанией
собственное облако сообщества
(on-site-community)
Применяется к облакам сообществ, реализованным на площадке заказчиков, составляющих сообщество
облако сообщества на аутсоурсинге
(outsourced-community)
Применяется к облакам сообществ, чьи серверы (и другое аппаратное обеспечение – например, системы хранения) размещены на внешнем хостинге, обслуживаемом аутсоурсинговой компанией
публичное облако
(public)
Применяется к публичным облакам

Ниже рассматривается каждый из представленных сценариев границ применимости.

Следующие утверждения являются общими по своим границам применимости, т.е. корректны вне зависимости от модели развертывания или сервисной модели (т.е. модели оказания услуг):

Организации, рассматривающие возможность использования облачных вычислений, должны принимать во внимание эти общие соображения и их возможные последствия для своей бизнес-модели и достижения долгосрочных целей (миссии). Однако, недостаточно уделять внимание только общим аспектам облачных вычислений. Облака также описываются границами применимости одной или нескольких характеристик, представленными в Таблице 1. Организации, обсуждающие применение облаков, должны детально рассматривать аспекты использования различных сценариев (вариантов реализации с учетом границ применимости) облаков, которые являются предметом такого обсуждения. Каждая из альтернатив самостоятельно рассматривается ниже в отдельном разделе (этого и, более обширного, оригинального) документа, фокусируясь на заданных границах применимости (4).

4) Этот документ не повторяет те или иные фрагменты текста. Однако, для конкретных типов облаков, может быть описано больше соображений, значимых для каждого конкретного типа; в этом случае, название общей характеристики/утверждения может использоваться снова, но с объяснением, специфичным для конкретного типа облака.

 

4.1 Понимание того, кто контролирует ресурсы в облаке
(Understanding Who Controls Resources in a Cloud)

Иногда утверждается, что при сравнении использования облаков с традиционной моделью “внутренних” (on premises) вычислений, облачная модель  требует от подписчиков передачи провайдеру двух важных возможностей, предполагающих высокий уровень доверия подписчика к провайдеру:

Однако, границы контроля и видимости, которые необходимо передать провайдеру со стороны подписчиков, зависят от многих факторов, включая физическое владение и возможность конфигурирования (с высоким уровнем доверия) механизмов защиты границ доступа к вычислительным ресурсам подписчиков.
  
Этот документ использует концепцию границ доступа (access boundaries) для структурирования и характеристики различных моделей развертывания облаков. Рисунок 2 иллюстрирует ключевую концепцию компьютерной безопасности*, связанную с границами и контролем – периметр безопасности (security perimeter). Как показано на рисунке, периметр безопасности выполняет роль барьера в отношении <операций> доступа: сущности, которые находятся внутри периметра, могут производить свободный доступ к ресурсам, находящимся только внутри периметра; однако, сущности, находящиеся за пределами периметра, могут получать доступ к ресурсам внутри периметра если только это разрешено средствами контроля границ (контроллер границ - boundary controller) на основе применения соответствующих политик доступа. Несмотря  не то, что эти термины часто используются при обсуждении сетевых экранов и сетей, концепция периметра безопасности, в действительности. Является более общей и может использоваться, например, для описания границ между различными уровнями привилегий выполнения программного обеспечения, т.е. границ <между> приложениями и операционной системой. Само по себе определение периметра безопасности НЕ является адекватным механизмом обеспечения безопасности. Однако контроль периметра безопасности является важным элементом построения безопасных систем.

*) необходимо отметить, что именно стандарты и рекомендации NIST в области компьютерной/информационной безопасности, в большой степени, определили фундамент и продолжают определять концептуальную основу и подходы к теории и практическому обеспечению безопасности в индустрии информационных технологий.

Типичные контроллеры границ включают сетевые экраны (firewalls), средства блокирования доступа (guards) и виртуальные частные сети (VPN - Virtual Private Networks). Организация может добиться оценки количественных показателей как в отношении контроля использования ресурсов, так и мониторинга доступа к ним (5). Более того, переконфигурируя периметр безопасности, организация может адаптировать его к меняющимся потребностям (например, блокирования или разрешения протоколов или форматов данных, исходя из изменений бизнес-условий).

5) Когда существуют неконтролируемые пути <доступа> к компьютерным ресурсам, периметр безопасности является нарушенным (в оригинале – ослабленным, weakened) или даже отсутствующим. Распространяющиеся беспроводные коммуникации, например, являются угрозой периметру безопасности, начиная с того, что не может быть надежного пути внедрения <контроллера границ> между внешними и внутренними сущностями. Аналогично, многие организации используют мобильные устройства, которые иногда подключаются <к ресурсам>, находясь внутри периметра, а иногда остаются без <должной защиты>, например, во время поездок.

Различные модели развертывания облаков, описанные в определении облачных вычислений NIST, подразумевают размещение контролируемого подписчиком периметра безопасности и, следовательно, уровень контроля, который подписчики могут осуществлять в отношении ресурсов, доверяемых облаку (т.е. передаваемых под управление провайдера облака с определенным уровнем доверия этому провайдеру).

Figure 2: Периметр безопасности

Определение облачных вычислений NIST описывает четыре модели развертывания: частное облако (private), облако сообщества (community), публичное облако (public), и гибридное облако (hybrid). Однако, каждая из моделей частного облака и облака сообщества допускают два варианта - сценария <развертывания>, которые должны рассматриваться по отдельности, по причине влияния на периметр безопасности: будет ли он собственный (on-site) или на аутсоурсинге (outsourced). Гибридная модель развертывания является комбинацией других моделей и, поэтому, гибридное развертывание может предполагать и влияние <на периметр безопасности> его элементов - "строительных блоков", и уникальные аспекты влияния, возникающие в результате объединения множества систем в более комплексные интегрированные системы.

 

4.2 Сценарий собственного частного облака (The On-site Private Cloud Scenario)

Рисунок 3 представляет простой взгляд на собственное частное облако (on-site private cloud). Как показано на рисунке, периметр безопасности простирается вокруг собственных ресурсов подписчика и ресурсов приватного облака. Приватное облако может быть централизованным на одной площадке или распределенным между несколькими площадками подписчика. Периметр безопасности будет существовать только в том случае, если подписчик его реализует. В случае реализации, периметр не гарантирует контроля всех ресурсов частного облака, но его существование дает подписчику возможность осуществлять контроль ресурсов, доверенных собственному частному облаку.

Рисунок 3: Собственное частное облако

Несмотря на то, что общие предположения остаются верными для собственного частного облака, этот сценарий позволяет предположить и другие, в т.ч. более детально описанные аспекты, которые необходимо принять во внимание организациям, рассматривающим использование собственных частных облаков:

  • Зависимость от сети (Network dependency) – собственное частное облако (on-site-private).
    В зависимости от конфигурации (например, один физический сайт, защищенная сеть облака), зависимость от сети для собственного частного облака может ограничиваться зависимостью от сетевых ресурсов, которые контролирует подписчик (например, локальная сеть). В этом сценарии могут быть исключены такие проблемы сетей большого масштаба (large-scale networks), как “заторы” Интернет или коммуникации с удаленными (в смысле remote) серверами доменных имен Интернет (Internet DNS). Кроме того, если реализован периметр безопасности для высоких уровней защиты, не во всех случаях становится необходимым применение таких механизмов защиты, как много-факторная аутентификация и сквозное шифрование при обмене внутри периметра даже при достаточно осторожных (минимизирующих соответствующие риски) политиках безопасности.

    Если организация-подписчик обладает множеством физических площадок и организовывает доступ с различных площадок к одному и тому же приватному облаку, подписчик должен обеспечить контроль коммуникаций между площадками, (например, линии связи с шифрованием) или использовать криптографические средства (например, VPN) поверх менее контролируемых средств коммуникаций, таких как публичный Интернет. Обе эти опции обладают рисками сетевой доступности и безопасности частного облака, в силу того, что существует зависимость от производительности  ресурсов (коммуникационных средств), находящихся за пределами области, контролируемой подписчиком, и потому, что любые ошибки в реализации и конфигурировании криптографических механизмов могут позволить получить доступ извне.

  • Подписчики должны обладать навыками в ИТ (Subscribers still need IT skills) – собственное частное облако (on-site-private). Организации-подписчики будут нуждаться в традиционных ИТ-навыках, необходимых для управления пользовательскими устройствами, с которых осуществляется доступ в частное облако, при этом для них актуальны требования по наличию навыков и в части облачных технологий. Ранее, на этапе развертывания собственного частного облака, организации-подписчики могут захотеть параллельно поддерживать в течение определенного промежутка времени* и облачные и традиционные средства.

    *) Существует множество факторов, влияющих на выбор систем, подлежащих переносу на облачную инфраструктуру. Можно предположить, что далеко не все ресурсы организации будут переводиться в облачную инфраструктуру, как по причине технологических ограничений и специфических требований многих решений, используемых в корпоративной среде, так и в силу финансовых аспектов перехода на облачные версии (в случае их существования и доступности для приобретения) эксплуатируемых традиционных систем. Таким образом, сосуществование (с той или иной границей разделения и объемами использования) облачной и собственной традиционной инфраструктуры представляется наиболее вероятным сценарием организации корпоративных ИТ, что предъявляет и дополнительные требования не только к навыкам, но и к другим общим аспектам применения облачных технологий.

    Кроме того, могут требоваться новые навыки для работы с облаками. Например, организациям, выполняющим работы, требующие интенсивных вычислений, может потребоваться со временем реорганизовать эти работы таким образом, чтобы они могли использовать высокий уровень параллелизма облачных ресурсов. Организациям,  обрабатывающим большие объемы данных, в свою очередь, может потребоваться развитие навыков использования облачных систем хранения (в общем смысле, а не только аппаратных).

  • Место выполнения рабочих нагрузок назначается динамически и скрыто от клиентов (Workload locations are hidden from clients) – собственное частное облако (on-site-private). Как и в общем случае, частное облако, с точки зрения управления аппаратными ресурсами, должно обеспечивать возможность миграции рабочих нагрузок между машинами <физическими узлами> без причинения клиентам каких-либо неудобств, т.е. даже без необходимости клиентам знать об этом. В то же время, в случае собственного частного облака, организация подписчика выбирает физическую инфраструктуру для развертывания и эксплуатации частного облака и, следовательно, определяет возможное географическое размещение места выполнения рабочих нагрузок. И если индивидуальные клиенты могут не знать, где именно их рабочие нагрузки физически выполняются в данный момент времени в терминах инфраструктуры организации подписчика, сама организация обладает таким знанием и контролем всех рабочих нагрузок, которым разрешено выполняться <в собственном частном облаке>.

  • Риски множественной аренды (Risks from multi-tenancy) – собственное частное облако (on-site-private). Как и в общем случае, рабочие нагрузки различных клиентов могут выполняться одновременно в тех же системах и сетях, будучи разделенными только с помощью политик доступа, определенных на уровне программного обеспечения провайдера. Уязвимости в этом программном обеспечении или в политиках могут нанести урон безопасности организации подписчиков, делая рабочие нагрузки клиентов видимыми/доступными другим сторонам, в нарушение политик безопасности. Собственное частное облако <по своей природе> в какой-то степени смягчает эти риски, <изначально> ограничивая число возможных нарушителей; обычно, все клиенты являются членами организации-подписчика или авторизованными партнерами или гостями (guest в терминах сетевого доступа), однако, собственное частное облако остается уязвимым к атакам, производимым авторизованными, но имеющими злой умысел инсайдерами. Различные организационные функции, такие как платежные ведомости, хранилища персональных данных или созданная интеллектуальная собственность, могут быть подвержены тем же уязвимостям в безопасности, которые могут позволить предоставить доступ пользователям, неавторизованным для доступа к определенным классам данных, и которые могут раскрыть данные <во вне> из собственного частного облака.

  • Импорт/экспорт данных и ограничения возможности их выполнения (Data import/export, and performance limitations) – собственное частное облако (on-site-private). Как и в общем случае, требуемые операции пакетного (bulk) импорта и экспорта ограничены пропускной способностью сети, а работа в режиме реального времени или обработка критически важных запросов могут оказаться проблематичны, в силу сетевых ограничений (в том числе, задержек при передаче данных по сети – network latency). В частном случае, если у подписчика есть только одна площадка, которой требуется доступ к собственному частному облаку, подписчик может быть обеспечен доступом к локальной сети, предоставляющей более высокую производительность, чем та, которая может быть достигнута при доступе через глобальную сеть.

  • Потенциально более строгая защита от внешних угроз (Potentially strong security from external threats) – собственное частное облако (on-site-private). При использовании собственного частного облака, подписчик имеет возможность реализации соответствующего <более> строгого периметра безопасности для защиты ресурсов частного облака от внешних угроз, чем это может быть достигнуто для ресурсов, не относящихся к облаку. Для не столь значимых данных (low-impact data – данные, риск утечки которых может привести лишь к незначительным последствиям или вообще не имеет значения) и их обработки, периметр безопасности может содержать  <лишь стандартные> наборы правил, определяемые коммерческими сетевыми экранами и VPN. Для более значимых данных, периметр безопасности может создаваться с применением более строгих ограничивающих политик сетевых экранов, многофакторной аутентификации и даже его физического изолирования.

  • Значительные первичные инвестиции в построение и миграцию облака (Significant-to-high up-front costs to migrate into the cloud) – собственное частное облако (on-site-private). Собственное частное облако требует установки программного обеспечения для управления облаком на вычислительных системах организации-подписчика. Если планируется, что облако будет поддерживать рабочие нагрузки, предполагающие интенсивные вычисления или обработку данных, <соответствующее> программное обеспечение должно быть установлено на большом количестве широко-распространенных (более дешевых - commodity) систем или на меньшем количестве высокопроизводительных (более дорогих) систем. Установка облачного программного обеспечения и управление такой инсталляцией приведет к значительным первичным вложениям (up-front costs), даже если облачное программное обеспечение является свободным, и даже если большая часть <планируемого к использованию в облаке> оборудования уже существует в организации. Существует три возможных подхода в построении собственного частного облака:

    Новый ЦОД - центр обработки данных, датацентр (NewDataCenter): Наиболее прямолинейный подход для подписчика - создать <выделенный> ЦОД, в котором будет развернуто облачное программное обеспечение. В этом случае, собственное частное облако предполагает затраты, аналогичные инвестициям в типичный датацентр и подписчик может подготовить его для ожидаемых рабочих нагрузок.

    Трансформация ЦОД (ConvertedDataCenter): В качестве альтернативы созданию нового ЦОД, подписчик может целиком трансформировать существующий датацентр или его отдельные части для поддержки собственного частного облака. Этот подход, однако, может привести к несовместимости параллельного функционирования облачных и обычных необлачных систем в течение периода их сосуществования.

    Очистка ресурсов (ScavengedResources): Другим альтернативным подходом является установка облачного программного обеспечения на уже существующие в организации компьютеры. В этом сценарии облачные системы разделяют аппаратные ресурсы с другими формами использования оборудования и могут существенно улучшить утилизацию ресурсов, которые в противном случае могли бы простаивать. Этот подход дает преимущество предложения облачных сервисов на экспериментальной основе без больших инвестиций в оборудование; однако,  ресурсы, доступные в такой конфигурации будут ограничены существующими излишками аппаратных ресурсов, присутствующими в инфраструктуре организации (до тех пор, пока предыдущие способы использования оборудования не будут сокращена <до минимума> и оно <в максимальном объеме> не будет передано под использование облака).

    Дополнительные ограничения включают:
    (1) аппаратные ресурсы должны как можно раньше встраиваться (инкорпорироваться) в собственное частное облако, вне зависимости от того, где они существуют в инфраструктуре организации подписчика (будучи используемыми по сети), несмотря на большую эффективность колокейшена (совместного физического размещения);
    (2) доступное оборудование может не быть однородным и это будет приводить к дополнительным сложностям в администрировании.

  • Ограниченные ресурсы (Limited resources) – собственное частное облако (on-site-private). В любой заданный момент времени, собственное частное облако обладает фиксированной вычислительной мощностью и емкостью систем хранения, которые могут быть выделены для соответствующих ожидаемых рабочих нагрузок. Собственное частное облако предполагает соответствующие стоимостные ограничения. Если организация достаточно велика и поддерживает достаточно большое разнообразие рабочих нагрузок, собственное частное облако может быть способным в рамках организации обеспечить клиентам необходимую эластичность. В то же время, меньшие <по доступным ресурсам> собственные частные облака будут демонстрировать пределы максимальной загрузки аналогично тому, как это происходит с традиционными центрами обработки данных. Собственное частное облако также требует осуществления первичных инвестиций (например, в оборудование) еще до того, как облако станет доступно подписчикам.

(время поиска примерно 20 секунд)

Знаете ли Вы, почему "черные дыры" - фикция?
Согласно релятивистской мифологии, "чёрная дыра - это область в пространстве-времени, гравитационное притяжение которой настолько велико, что покинуть её не могут даже объекты, движущиеся со скоростью света (в том числе и кванты самого света). Граница этой области называется горизонтом событий, а её характерный размер - гравитационным радиусом. В простейшем случае сферически симметричной чёрной дыры он равен радиусу Шварцшильда".
На самом деле миф о черных дырах есть порождение мифа о фотоне - пушечном ядре. Этот миф родился еще в античные времена. Математическое развитие он получил в трудах Исаака Ньютона в виде корпускулярной теории света. Корпускуле света приписывалась масса. Из этого следовало, что при высоких ускорениях свободного падения возможен поворот траектории луча света вспять, по параболе, как это происходит с пушечным ядром в гравитационном поле Земли.
Отсюда родились сказки о "радиусе Шварцшильда", "черных дырах Хокинга" и прочих безудержных фантазиях пропагандистов релятивизма.
Впрочем, эти сказки несколько древнее. В 1795 году математик Пьер Симон Лаплас писал:
"Если бы диаметр светящейся звезды с той же плотностью, что и Земля, в 250 раз превосходил бы диаметр Солнца, то вследствие притяжения звезды ни один из испущенных ею лучей не смог бы дойти до нас; следовательно, не исключено, что самые большие из светящихся тел по этой причине являются невидимыми." [цитата по Брагинский В.Б., Полнарёв А. Г. Удивительная гравитация. - М., Наука, 1985]
Однако, как выяснилось в 20-м веке, фотон не обладает массой и не может взаимодействовать с гравитационным полем как весомое вещество. Фотон - это квантованная электромагнитная волна, то есть даже не объект, а процесс. А процессы не могут иметь веса, так как они не являются вещественными объектами. Это всего-лишь движение некоторой среды. (сравните с аналогами: движение воды, движение воздуха, колебания почвы). Подробнее читайте в FAQ по эфирной физике.

НОВОСТИ ФОРУМАФорум Рыцари теории эфира
Рыцари теории эфира
 01.10.2019 - 05:20: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вячеслава Осиевского - Карим_Хайдаров.
30.09.2019 - 12:51: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Дэйвида Дюка - Карим_Хайдаров.
30.09.2019 - 11:53: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Владимира Васильевича Квачкова - Карим_Хайдаров.
29.09.2019 - 19:30: СОВЕСТЬ - Conscience -> РУССКИЙ МИР - Карим_Хайдаров.
29.09.2019 - 09:21: ЭКОНОМИКА И ФИНАНСЫ - Economy and Finances -> КОЛЛАПС МИРОВОЙ ФИНАНСОВОЙ СИСТЕМЫ - Карим_Хайдаров.
29.09.2019 - 07:41: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Михаила Делягина - Карим_Хайдаров.
26.09.2019 - 17:35: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Андрея Пешехонова - Карим_Хайдаров.
26.09.2019 - 16:35: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> Проблема государственного терроризма - Карим_Хайдаров.
26.09.2019 - 08:33: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от О.Н. Четвериковой - Карим_Хайдаров.
26.09.2019 - 06:29: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Ю.Ю. Болдырева - Карим_Хайдаров.
24.09.2019 - 03:34: ТЕОРЕТИЗИРОВАНИЕ И МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ - Theorizing and Mathematical Design -> ФУТУРОЛОГИЯ - прогнозы на будущее - Карим_Хайдаров.
24.09.2019 - 03:32: НОВЫЕ ТЕХНОЛОГИИ - New Technologies -> "Зенит"ы с "Протон"ами будут падать - Карим_Хайдаров.
Bourabai Research Institution home page

Боровское исследовательское учреждение - Bourabai Research Bourabai Research Institution