<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <journal-title-group>
        <journal-title>Kyiv, Ukraine, June</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Analysis of Methods for Providing Availability and Accessibility of Cloud Services</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Max Yanovsky</string-name>
          <email>M.Yanovsky@csn.khai.edu</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Olga Yanovskaya</string-name>
          <email>O.Yanovskaya@csn.khai.edu</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Vyacheslav Kharchenko</string-name>
          <email>V.Kharchenko@khai.edu</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="editor">
          <string-name>Key Terms. ICTInfrastructure, ICTComponent, WebService, FormalMethod</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Centre for Safety Infrastructure-Oriented Research and Analysis 17</institution>
          ,
          <addr-line>Chkalova St., 61070 Kharkiv</addr-line>
          ,
          <country country="UA">Ukraine</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>National Aerospace University named after N.E. Zhukovsky "KhAI" 17</institution>
          ,
          <addr-line>Chkalova St., 61070 Kharkiv</addr-line>
          ,
          <country country="UA">Ukraine</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2016</year>
      </pub-date>
      <volume>2</volume>
      <fpage>1</fpage>
      <lpage>24</lpage>
      <abstract>
        <p>The article describes methods for dealing with reliability and fault tolerance issues of cloud datacenters. These methods are mainly focused on the elimination of single point of failure within any component of the cloud infrastructure, including the availability of infrastructure and accessibility of cloud services. The methods for providing the availability of hardware, software and network components are also presented. The analysis of the actual accessibility of the cloud services and the matching of cloud datacenter infrastructure with the level of reliability according to the Tier Classification System is described. Non-compliance of the actual accessibility with the level of High Availability for cloud web services was found.</p>
      </abstract>
      <kwd-group>
        <kwd />
        <kwd>Availability</kwd>
        <kwd>Accessibility</kwd>
        <kwd>Cloud Datacenter</kwd>
        <kwd>Service Reliability</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>High availability is a critical issue for the cloud datacenter. Thus, estimating the
financial loss due to the failure of datacenter components, which would result in
unavailability of services, is a major part of an economic development plan for any
cloud datacenter customer. The complexity of the architecture, meaning the large
number of components and diversity approaches in designing the structure of the
network infrastructure, causes issues in obtaining accurate evaluation of reliability,
availability and accessibility of such systems.</p>
      <p>
        In order to ensure end-user quality of service, the required cloud system should
have the appropriate characteristics of reliability and performance. The term
reliability refers to the property of an object or system to maintain, over time and within the
prescribed limits, the ability to perform the required functions in set modes and
conditions of use, maintenance, repair, storage and transportation according to ISO
238214:1978 [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. A major property is failure-free operation, a property of an object that
refers to permanent operability during some period of time. Time to failure – time to
      </p>
      <p>- 415
the first failure: This property is characterized by the probability of failure-free
operation – likelihood of absence of failure within a given operating time.</p>
      <p>The main internal property of reliability is availability. Availability reflects the
system's ability to perform its functions continuously. The availability coefficient is
defined as the probability that at any given time t the object is in working state s, except
for maintenance periods during which there is no intended use of the system.
However, according to the concept of cloud-based architecture, the concept of availability
as the main internal property of reliability refers to the entire infrastructure: the value
of the availability factor will be determined based on how efficient the functional state
of the system is considered and under what conditions the state of the system can be
considered workable. The article considers methods for providing the availability of
cloud infrastructure and accessibility of cloud services, as well as analyzes the
effectiveness of their application based on studies for actual availability of cloud providers'
services.
2</p>
    </sec>
    <sec id="sec-2">
      <title>State of the Art</title>
      <p>
        Studies’ analysis [
        <xref ref-type="bibr" rid="ref2 ref3">2, 3</xref>
        ] leads to the conclusion that currently there is ambiguous
interpretation of cloud datacenter operability conditions as it depends on the number of
available and unavailable services in relation to the total amount of services, at the
current time. Seeing as the end user interacts with a specific service of the cloud
datacenter, the term of cloud service accessibility is suggested to be used.
Analysis of the sources [
        <xref ref-type="bibr" rid="ref4 ref5">4, 5</xref>
        ] shows that the most common availability indicator is
determined by the following formula:
      </p>
      <p>Ka = MTTF/(MTTF + MTTR),
(1)
where Ka – availability coefficient,
MTTF – mean time to failure,
MTTR – mean time to recover.</p>
      <p>Property of accessibility determines the probability that at any time a certain cloud
service will be available to the end user with a satisfactory response time. The main
factor is the accessibility coefficient, which includes not only the availability, but also
the functional properties of the system.</p>
      <p>With increasing demands on the quality of services in the IT-infrastructure, any
kind of failures in the network are unacceptable. Even a relatively small packet loss
can have a negative impact on the end-users’ quality of service, especially for critical
and business-critical processes, so the failure of the main switching node, link or
interface may have serious consequences for the provider. The design of the cloud
datacenter should help minimize network failures and the severity of the consequences of
potential accidents.</p>
      <p>
        Advances in technology and the pace of construction of virtual data centers and
cloud infrastructures have caused the development of requirements for the distribution
functions of management control across multiple geographically dispersed nodes, the
division of responsibility between the teams of technical personnel, the extension of
monitoring and diagnostics functions support high availability and disaster recovery.
According to [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], the datacenter design should include redundant components and
distributed platforms, so that the physical connection and access to resources remain
constant, regardless of the location and value of the current availability and
performance indicators. Furthermore, to protect the competitiveness of enterprises and
organizations that are customers of cloud providers, critical business applications need
to be available 24/7. In case of environmental or technological disasters, the data must
be restored with minimal disruption, calling for an emergency backup and recovery of
business applications and the virtual machine in a different availability zone will
ensure that user data is protected and accessible from anywhere.
      </p>
      <p>
        Typically, network architects predict a 4 or 5 "nines" system availability [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ].
However, each additional digit = "9" can significantly increase the cost of deployment. To
achieve near-zero downtime per year of the cloud data center, one must consider not
only the reliability of the hardware and network infrastructure, but also part of
software.
3
      </p>
    </sec>
    <sec id="sec-3">
      <title>Classification of Cloud Data Centers Based on Tier Standard</title>
      <p>
        Cloud datacenter reliability levels have been identified in the documents "Data Center
Site Infrastructure Tier Standard: Topology" [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] and "Data Center Site Infrastructure
Tier Standard: Operational Sustainability" [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] of the world organization Uptime
Institute [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], which are engaged in the development and verification of detailed
requirements for a fault-tolerant datacenter infrastructure, certification and issuance of
recommendations and expert advice on data center infrastructure according to the level
of reliability.
      </p>
      <p>
        Uptime Institute Certification on levels of reliability meets the standard
ANSI/TIA942-A [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. Classification of data center infrastructure by levels of reliability is carried
out on the basis of these basic criteria, the degree of redundancy of equipment and
communication channels, the meeting of performance characteristics, functionality,
efficiency and expected availability level. The requirements and recommendations
apply to the following systems and components:
─ architecture and topology;
1. TIER I: Basic Site Infrastructure;
2. TIER II: Redundant Site Infrastructure Capacity Components;
3. TIER III: Concurrently Maintainable Site Infrastructure;
4. TIER IV: Fault Tolerant Site Infrastructure.
      </p>
      <p>Datacenter infrastructure and operating expenses increase in accordance with the
reliability level, which gives grounds for datacenter owners to choose the class of
reliability at the designing stage and in accordance with their business needs. The
results of the comparative analysis of the datacenter infrastructure reliability levels are
shown in the table below.
Based on the results of this analysis, the following conclusions are made:
1. The existing Tier Classification System for the reliability assessment of the
datacenter infrastructure in terms of business requirements for system performance
does not consider the reliability of software components.</p>
      <p>2. The classification system of datacenter reliability on Tier levels does not
explicitly consider the characteristics of the equipment, such as mean time to failure, which
is not correct in assessing the availability of the system.</p>
      <p>3. Deploying cloud and business-critical applications requires the highest level of
availability TIER IV datacenter infrastructure.</p>
      <p>4. During operation of the cloud datacenter and appending servers and equipment
within a constant engineering infrastructure needs may change in the required
resources, which may lead to a change in the datacenter reliability. Thus, it is necessary
to review and confirm the level of reliability of the datacenter, as well as to ensure the
effective operation by highly trained personnel and administration.</p>
      <p>In order to meet the levels of reliability and maintenance of the set level of
availability and accessibility of cloud infrastructure services, a variety of methods are used
to ensure fault tolerance in the core, aggregation and access layers. The main purpose
of the application of methods is to ensure availability, which means to eliminate
points of single failure of any component of the cloud infrastructure (hardware,
software, network) at any layer (core, aggregation, access). Since hardware failure and
software faults may appear in components at any layer, there are methods of fault
tolerance for each of them. The methods are used to ensure the availability of cloud
services at different levels of the architecture will be considered.
4</p>
    </sec>
    <sec id="sec-4">
      <title>Methods for Providing Availability of Hardware Components</title>
      <p>The objective of this group of methods is to maintain the availability of cloud services
and applications in case a particular server becomes unavailable. The method can
operate at multiple levels within the datacenter infrastructure. Hardware component
accessibility methods are used at the physical layer ISO/OSI model. These include the
following.
 Grouping of network adapters and communication channels.</p>
      <p>In order to eliminate single points of failure at the level of communication with
network, access layer servers have multiple (two or more) network interfaces (Fig. 1).
This method is named NIC-Teaming and it involves the grouping of multiple physical
connections into one logical channel - LAG (Link Aggregation). The logical
connection may be in active-active mode that combines multiple channels into a single
logical load sharing or active-passive mode, wherein the second interface is idle as long
as the first interface operates as usual.
 Using hot-swappable interfaces.</p>
      <p>This method requires the ability to install or remove the interface card on the router
or switch without having to power off the device. The controller dynamically
recognizes the new interface and begins the data exchange. As a result, new components
can be inserted and removed without interrupting the system’s operation.
 Use of highly reliable server access layer.</p>
      <p>Hardware components of highly reliable servers have the highest values of MTTF.
5</p>
    </sec>
    <sec id="sec-5">
      <title>Methods for Providing Availability of Software Components</title>
      <p>
        An analysis [
        <xref ref-type="bibr" rid="ref10 ref11">10, 11</xref>
        ] found that the main methods of resilience at the application level
are the use of pooling resources, protected applications and resources of critical
applications as well as and the migration of virtual machines and the use of Unified
InService Software Upgrades.
      </p>
      <p>Cloud
datacenter
networking
Users</p>
      <p>Cloud
datacenter
networking</p>
      <p>. . .
 Transfer of critical application resources.</p>
      <p>Application pool</p>
      <p>resource
Critical resources
of Applications</p>
      <p>Some applications have critical resources, that for various reasons are not possible
or desirable to replicate. They can either work on the basis of high-performance
servers, that makes replication too expensive, or they can include critical resources that
makes replication not possible due to security threats or exploitation reasons.</p>
      <p>Under these conditions, one application server is a single point of failure. In order
to minimize the risk of failure for critical resources of applications, the execution of
these applications are made on several powerful servers, failover and high availability
provided by the active / standby configuration mode for disaster recovery. Connection
problems are solved by multisession network connections between the server and
clients, and multiple network routes (Fig. 3).</p>
      <p>Conditions of effective application of this method are the presence of redundant
network links and backup systems as well as continuous monitoring of the status of
servers and data replication, in order to maintain synchronization of the active and
standby systems.
 Migration of virtual machines.</p>
      <p>Virtual machine migration is an effective method for providing fault-tolerance and
for maintaining service availability in the event of a failure of the physical server on
which it is running. This method assumes that the virtual machine has its own running
copy on a server located in another rack or in another datacenter. In this case, services
that are deployed on the initial virtual machine are replicated on another virtual
machine.
 Using a single integrated service system updates.</p>
      <p>
        The ability to provide unified system ISSU (Unified In-Service Software
Upgrades) updates of an operating system without shutting down network devices that
are scheduled for preliminary verification of compatibility, is supported by some
versions of operating systems within a number of network equipment manufacturers
[
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], thus avoiding the risks associated with downtime and failed updates of network
operating systems.
6
      </p>
    </sec>
    <sec id="sec-6">
      <title>Methods for Providing Availability of Network Components</title>
      <p> Redundant network devices</p>
      <p>The analysis of the examined standards and guidelines for the design of the
datacenter allows us to determine that the redundancy of network devices as a method of
fault tolerance, involves the duplication of the core level routers, access layer and
distribution switches.</p>
      <p>Additional mechanisms for balancing the load between them increase network
performance and reduce latency.</p>
      <p>Apart from that, in order to minimize the effects of a single point of failure, the
network device may also be used in methods such as hot-swappable interface, Unified
In-Service Software Upgrades, redundant switching and routing mechanisms.
 Redundant switching and routing mechanisms</p>
      <p>The main purpose of this method is to create redundant switching for network
devices.</p>
      <p>Along with a redundant configuration, switching fabric with two switch modules is
used to increase the capacity and performance the switch. The third module, if
present, provides an additional precision (2 + 1) for switching functions, so that if one of
the two functional modules becomes inoperable, a third module can take over the
function of the failed module. Redundant routing mechanisms provide simultaneous
operation of multiple routing protocols as well as protection from the routing and
switching loops based on the following protocols, technology and standards:
─ L3 dynamic routing protocols in the core level (OSPF, RIP, or static routing);
─ Multiple Spanning Tree Protocol (MSTP);
─ MPLS in the core level;
─ 802.3ad LAG;
─ 802.1q Virtual LANs;
─ RTG (Redundant trunk groups);
─ VRRP;
─ MPLS in the aggregation level.</p>
      <p>Based on the analysis, the presented methods highlight a number of common
disadvantages in their application: complexity of the architecture, the processes of its
maintenance and operation due to demand for high priced resources, additional
overhead costs on excess equipment and permanent high-quality maintenance. In order to
determine the effectiveness of the methods and architecture considered, an analysis of
the accessibility of services from known cloud providers should be conducted.
7</p>
    </sec>
    <sec id="sec-7">
      <title>Analysis of Actual Services Accessibility of Cloud Providers</title>
      <p>
        The values shown in the above histograms are obtained by analyzing the actual
values of downtime for a time period of 1 year, as published by Cloud Harmony [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]
for the service models of PaaS and IaaS [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ].
      </p>
      <p>According to the analysis of the actual accessibility of cloud providers' services,
and as shown by the values represented in the histograms, we can conclude that the
average accessibility of a datacenter's cloud services corresponds to a value of 0.999.</p>
      <p>In order to determine whether the claimed quality of the service is in compliance
with the actual quality of service, an analysis of the service-level agreement (SLA) of
known cloud providers was performed. The results of the analysis are summarized in
the table 2.</p>
      <p>In order to verify compliance of the datacenter infrastructure cloud providers with
levels of reliability according to the Tier Classification System, made analysis of the
data with characteristics of the datacenter provided by cloud providers. The results of
the analysis are presented in the table 3.</p>
      <p>Analysis of the results leads to the conclusion: despite the fact that the cloud
datacenter infrastructure matches the fourth level of reliability with an availability
coefficient of 0,99995, the actual average access-infrastructure of cloud service providers,
on average, corresponds to a value of 0.999. Therefore, it is necessary to improve the
models and methods of assessing the availability and accessibility for services of
client-server cloud infrastructure to obtain more accurate estimates of the reliability
indices.
8</p>
    </sec>
    <sec id="sec-8">
      <title>Case study</title>
      <p>This section provides the results of a case study on accessibility, based on the
simulation model of the cloud server that is running 3 virtual machines.</p>
      <p>
        The results of the statistical analysis of time characteristics of the
WEBapplications servers’ performance [
        <xref ref-type="bibr" rid="ref24">24</xref>
        ] confirm that, based on a mathematical model
of computing systems, it can be assumed that the random variables: time of the
requests towards the server has an exponential distribution, and the input query is a
Poisson series ( QS M/M/1). Based on this assumption, a model was found. Requests
arrive to the physical server network card (Physical NIC), then are distributed among
the virtual network interfaces and are processed there. In this model, another element
to the input stream applications was added: that of lost requests, due to loss of server
performance (hardware failure, operating system or hypervisor refusal). It can be
assumed that hardware failures occur on average once every 300,000 hours, with
mean time between OS failures is 1440 hours, and the hypervisor is 2880 hours.
The resulting value, obtained as a percentage of processed requests on the time
line, is as follows:
      </p>
      <p>According to the results shown in the graph, it is evident that during the day
(24hour model) each unit of the system’s configuration, that has its test parameters on the
average percentage of time, processes user requests of about 96%.</p>
      <p>Almost all of the input parameters depend on the specific hardware and software
implementation of the system. The exception is the MTTR of hardware failure, the
operating system and the hypervisor as well as the corresponding recovery rate. The
experiments s conducted showed the recovery time takes an average of 1 to 2 hours.
The simulation results, when changing the data in this range, show a decrease in the
recovery times of up to 1 hour while it is possible to get an increase in availability
features in 4 digits.</p>
      <p>It is possible to improve this figure in several ways:
1) increase the average time between failures of hardware and software server;
2) decrease the time of exchange between physical and virtual network adapters,
which can be varied from a few milliseconds to tens of milliseconds, depending on
the specific application platform and hypervisor which implements virtual server
infrastructure.
9</p>
    </sec>
    <sec id="sec-9">
      <title>Conclusion</title>
      <p>The analysis methods for fault tolerance and availability of client-server cloud
infrastructure services were presented. These methods are more focused on the points of
single failure elimination for each component of the cloud infrastructure (hardware,
software, network) in every level (core, distribution, access), as well as models and
methods of estimating the availability and accessibility of cloud-based architectures.
The results of the analysis of the actual datacenter services accessibility of cloud
service provider for service models PaaS and IaaS, as well as compliance of datacenter
infrastructure of cloud providers with levels of reliability according to the Tier
classification were presented. Despite the use of different methods of fault tolerance in
cloud infrastructures, there is the problem of inconsistency of the actual system
availability level of "High Availability" for critical and business-critical web applications.
Thus, the direction of future research would be towards the improvement of the
models and methods so as to ensure accessibility of cloud services. Furthermore,
according to analysis results, it is important for the direction of future research results to find
an effective combination of the discussed methods for providing the required level of
availability and accessibility.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. ISO/IEC 2382-14: Information technology.
          <source>Vocabulary. Part</source>
          <volume>14</volume>
          :
          <article-title>Reliability, maintenance and availability (</article-title>
          <year>1997</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>R. S.</given-names>
            <surname>Couto</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. E. M.</given-names>
            <surname>Campista and L. H. M. K. Costa</surname>
          </string-name>
          :
          <article-title>A reliability analysis of datacenter topologies</article-title>
          ,
          <source>Global Communications Conference (GLOBECOM)</source>
          , IEEE, Anaheim, CA, pp.
          <fpage>1890</fpage>
          --
          <lpage>1895</lpage>
          . doi:
          <volume>10</volume>
          .1109/GLOCOM.
          <year>2012</year>
          .
          <volume>6503391</volume>
          (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>K. V.</given-names>
            <surname>Vishwanath</surname>
          </string-name>
          ,
          <string-name>
            <surname>N.</surname>
          </string-name>
          <article-title>Nagappan: Characterizing cloud computing hardware reliability</article-title>
          ,
          <source>in Proceedings of the 1st ACM symposium on Cloud computing (SoCC '10)</source>
          . ACM, New York, NY, USA, pp.
          <fpage>193</fpage>
          --
          <lpage>204</lpage>
          . doi:
          <volume>10</volume>
          .1145/1807128.1807161 (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Fernandes</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tavares</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Santos</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lira</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          , &amp;
          <string-name>
            <surname>Maciel</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Dependability assessment of virtualized networks</article-title>
          .
          <source>IEEE International Conference on Communications (ICC)</source>
          , pp.
          <fpage>2711</fpage>
          - -
          <lpage>2716</lpage>
          , Ottawa (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>5. Downtime Statistics of Current Cloud Solution,</mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6. http://iwgcr.org/wp-content/uploads/2014/03/downtime-statistics
          <source>-current-1</source>
          .3.pdf
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7. TIA/EIA-942:
          <article-title>Telecommunications Infrastructure Standard for Data Centers (</article-title>
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <given-names>Data</given-names>
            <surname>Center Site Infrastructure Tier Standart</surname>
          </string-name>
          : Topology,
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>9. https://uptimeinstitute.com/publications/asset/tier-standard-topology</mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Data Center Site Infrastructure Tier Standart</surname>
          </string-name>
          : Topology,
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11. https://uptimeinstitute.com/publications/asset/tier
          <article-title>-standard-operational-sustainability</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>12. About Uptime Institute, https://uptimeinstitute.com/about-ui</mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <article-title>Cisco Data Center Infrastructure 2.5 Design Guide</article-title>
          ,
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>14. http://www.scn.rain.com/~neighorn/PDF/Cisco_Data_Center_Infrastructure_Design_Guid e.pdf</mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Juniper</surname>
            <given-names>Networks</given-names>
          </string-name>
          ,
          <article-title>"Cloud Ready Data Center Network Design Guide",</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>16. http://www.juniper.net/us/en/local/pdf/design-guides/8020014-en.pdf</mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <article-title>Research and compare cloud providers</article-title>
          and services, https://cloudharmony.com/status
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>18. Cloud Computing Vendors Taxonomy, http://cloudtaxonomy.opencrowd.com/taxonomy</mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <article-title>SLA for App Service</article-title>
          , https://azure.microsoft.com/en-us/support/legal/sla/app-service
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <article-title>SLA for Virtual Machines</article-title>
          , https://azure.microsoft.com/en-us/support/legal/sla/virtualmachines
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>21. SLA for Cloud Services, https://azure.microsoft.com/en-us/support/legal/sla/cloud-services</mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>Google Compute Engine Service Level Agreement</surname>
          </string-name>
          , https://cloud.google.com/compute/sla
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <surname>Google App Engine Service Level Agreement</surname>
          </string-name>
          , https://cloud.google.com/appengine/sla
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          24.
          <string-name>
            <surname>Amazon EC2 Service Level Agreement</surname>
          </string-name>
          , https://aws.amazon.com/ru/ec2/sla
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>25. Cloud Service Level Agreement, https://www.rackspace.com/information/legal/cloud/sla</mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          26.
          <article-title>Amazon called out over cloud security,</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>27. http://www.techworld.com.au/article/326287/amazon_called_over_cloud_security_secrecy</mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>28. Microsoft Cloud Services,</mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>29. https://assets.digitalmarketplace.service.gov.uk/documents/93064/4504230568132608- pricing-document.pdf</mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          30.
          <string-name>
            <given-names>About</given-names>
            <surname>Rackspace</surname>
          </string-name>
          .
          <source>Global Infrastructure and Uptime Guarantee</source>
          ,
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>31. http://www.rackspace.com/about/datacenters</mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          32.
          <string-name>
            <surname>Gorbenko</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Romanovsky</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Time-Outing Internet Services. Security</surname>
          </string-name>
          &amp; Privacy, IEEE,
          <volume>11</volume>
          (
          <issue>2</issue>
          ), pp.
          <fpage>68</fpage>
          --
          <lpage>71</lpage>
          . doi:
          <volume>10</volume>
          .1109/MSP.
          <year>2013</year>
          .
          <volume>43</volume>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>