An application implemented on a server in a network of storage servers can be provided to manage the data replication relationships implemented between the storage servers of the network. In one embodiment, this server can be designated the manager server, and can include a network adapter to connect the manager server to a network, the network including a plurality of storage servers, the plurality of storage servers implementing a plurality of data replication relationships, and a storage facility to contain a data structure representing the plurality of data replication relationships to enable a user to centrally manage the plurality of data replication relationships.
|
14. A method for centrally managing a plurality of storage servers for data replication, the method comprising:
obtaining information from the plurality of storage servers about data replication relationships of data which the plurality of storage servers store, each data replication relationship including one or more relationship attributes;
establishing a replication policy for each data replication relationship based on the obtained information, including the one or more relationship attributes; and
applying the replication policy to one or more storage servers implementing the corresponding data replication relationship.
9. A method for centrally managing a plurality of storage servers for data replication, the method comprising:
creating a data structure representing a plurality of data replication relationships for the plurality of storage servers, wherein each data replication relationship identifies data to be replicated and a destination to which the data is to be replicated, each data replication relationship includes one or more relationship attributes, and the plurality of storage servers implement the plurality of data replication relationships;
creating a replication policy for each data replication relationship, based on the one or more attributes of said each data replication relationship; and
applying the replication policy to one or more storage servers which implement the corresponding data replication relationship.
17. A manager server for centrally managing a plurality of storage servers for data replication, the manager server comprising:
a database;
a network adapter to connect the manager server to a network, the network including the plurality of storage servers; and
a processor, coupled to the database and the network adaptor, to obtain information from the plurality of storage servers about a plurality of data replication relationships for the plurality of storage servers, each data replication relationship including one or more relationship attributes, to store the plurality of data replication relationships in the database, to establish a replication policy for each data replication relationship based on the obtained information, including the one or more relationship attributes, and to apply the replication policy to one or more storage servers implementing the corresponding data replication relationship over the network.
1. A manager server for centrally managing a plurality of storage servers for data replication, the manager server comprising:
a storage facility to store a data structure representing a plurality of data replication relationships for the plurality of storage servers, wherein each data replication relationship identifies data to be replicated and a destination to which the data is to be replicated, and each data replication relationship includes one or more relationship attributes;
a network adapter to connect the manager server to a network, the network including the plurality of storage servers, the plurality of storage servers implementing the plurality of data replication relationships; and
a processor to establish a replication policy for each data replication relationship, based on the one or more relationship attributes of said each data replication relationship and to apply the replication policy to one or more storage servers implementing the corresponding data replication relationship.
2. The manager server of
3. The manager server of
4. The manager server of
the processor updates the data structure stored in the storage facility, based on changes in the reported data replication relationships.
6. The manager server of
7. The manager server of
10. The method of
11. The method of
12. The method of
obtaining information about data replication relationships from the plurality of storage servers regarding data that the storage servers store; and
updating the data structure based on changes in the data replication relationships according to the information from the plurality of storage servers.
15. The method of
16. The method of
18. The manager server of
19. The manager server of
|
At least one embodiment of the present invention pertains to data storage and backup techniques, and more particularly, to a method and apparatus for managing data replication relationships.
A file server is a type of storage server that operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical storage based disks. The mass storage devices are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). One configuration in which file servers can be used is a network attached storage (NAS) configuration. In a NAS configuration, a file server can be implemented in the form of an appliance that attaches to a network, such as a local area network (LAN) or a corporate intranet. An example of such an appliance is any of the NetApp Filer products made by Network Appliance, Inc. in Sunnyvale, Calif.
A file server can be used to backup data, among other things. One particular type of data backup technique is known as data replication, and is sometimes referred to as “mirroring”. Data replication involves backing up data stored at a primary site by storing an exact duplicate (an image) of the data at a remote secondary site. The purpose is that, if data is ever lost at the primary site, it can be recovered from the secondary site.
In a simple example of a mirroring configuration, a source file server located at the primary site may be coupled locally to a first set of mass storage devices, to a set of clients through a local area network (LAN), and to a destination file server located at a remote site through a wide area network (WAN) or metropolitan area network (MAN). The destination storage server located at the remote site is coupled locally to a second set of mass storage devices at the secondary site.
Setting up and managing various data replication relationships in such a simple two file server system is relatively straightforward. However, in an environment with tens, hundreds, or even thousands of file servers, managing the data replication relationships becomes burdensome.
An application implemented on a server in a network of storage servers can be provided to manage the data replication relationships implemented between the storage servers of the network. In one embodiment, this server can be designated the manager server, and can include a network adapter to connect the manager server to a network, the network including a plurality of storage servers, the plurality of storage servers implementing a plurality of data replication relationships, and a storage facility to contain a data structure representing the plurality of data replication relationships to enable a user to centrally manage the plurality of data replication relationships.
One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
A method and apparatus for managing data replication relationships is described. Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the present invention. Further, separate references to “one embodiment” or “an embodiment” in this description do not necessarily refer to the same embodiment; however, such embodiments are also not mutually exclusive unless so stated, and except as will be readily apparent to those skilled in the art from the description. For example, a feature, structure, act, etc. described in one embodiment may also be included in other embodiments. Thus, the present invention can include a variety of combinations and/or integrations of the embodiments described herein.
Some portions of the detailed description that follows are presented in terms of algorithms and symbolic representations of operations on data within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the computer science arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it will be appreciated that throughout the description of the present invention, use of terms such as “processing”, “computing”, “calculating”, “determining”, “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
As indicated above, one embodiment of the present invention is instantiated in computer software, that is, computer readable instructions, which, when executed by one or more computer processors/systems, instruct the processors/systems to perform the designated actions. Such computer software may be resident in one or more computer readable media, such as hard drives, CD-ROMs, DVD-ROMs, read-only memory, read-write memory and so on. Such software may be distributed on one or more of these media, or may be made available for download across one or more computer networks (e.g., the Internet). Regardless of the format, the computer programming, rendering and processing techniques discussed herein are simply examples of the types of programming, rendering and processing techniques that may be used to implement aspects of the present invention. These examples should in no way limit the present invention, which is best understood with reference to the claims that follow this description.
As described in greater detail below, a server in a network of storage servers can be designated as a manager server to manage the data replication relationships implemented between the storage servers of the network. Central management can include the creation of replication policies that can be applied to individual relationships. A change to a policy can be automatically propagated to each relationship to which the policy applies, and conversely, a change in a policy can be automatically detected and used to update the policy controlling the relationship.
In this description, the first storage server 2 is referred to as the source storage server 2, while the second storage server 6 is referred to as the destination storage server 6. The blocks of data being replicated from the source storage server 2 to the destination storage server 6 are referred to as the data source, while the location on the destination storage server where the data is replicated to is referred to as the data destination. The data source and the data destination could be located on any storage means, such as storage disks (e.g., mass storage device 5), and other volatile or non-volatile memory.
A data source can be any amount of data designated for replication. For example, a data source can be some commonly used data amount, such as a volume, a quota-tree (Q-Tree), or some other unit of data management. The combination of a data source and a data destination is referred to as a “relationship,” or “data replication relationship.” That is, a relationship determines what the data to be replicated is and to where this data is to be replicated.
Each relationship can have attributes that determine the behavior of the relationship. One relationship attribute is the update schedule. The update schedule controls how often, e.g. once a week or every five minutes, the data source is replicated to the data destination.
Relationships can have various other attributes, such as a “throttle” value that specifies the amount of bandwidth each update transfer is allowed to consume. Other attributes can include a restart value to indicate whether an aborted transfer should restart, a lag warning (in units of time) to indicate the amount of time allowed to go by without an update before a warning is generated, and a lag error (in units of time) to indicate the amount of time allowed to go by without an update before an error message is generated. A relationship having such attributes is generally referred to as an asynchronous relationship, whereas a relationship that continually replicates the data is generally referred to as a synchronous relationship. In one embodiment, the relationship information is stored in the destination storage server, e.g., in a configuration file.
The source storage server 2 and destination storage server 6 are coupled to each other through a network 7, such as a WAN or MAN, but a LAN is also possible. Networks 3 and 7 each may be, for example, a TCP/IP network or a FibreChannel network.
The configuration of
As described above, the configuration shown
Also shown in
In another embodiment the manager server can be any computing server connected to the network, and can be implemented using software running on a Solaris, Linux, or Windows platform. Other similar platforms can also be used. The name “manager server” is purely descriptive; a manager server is any server being used by a user to centrally manage remote and local data replication relationships.
In one embodiment, the manager server is a server running a Data Fabric Manager™ (DFM) application on a server platform discussed above. DataFabric Manager is a simple, yet powerful application for managing a distributed storage infrastructure consisting of NetApp storage and NetCache content delivery systems. DFM's support for logical group formation enables administrators to effectively manage large numbers of distributed devices through one centralized interface. Common tasks such as device configuration, software upgrades, provisioning, backup, and monitoring are simplified through device and file system consolidation. Group-based management and monitoring not only alleviate the need for a large IT staff but also provide administrators with a global view of how their network and storage infrastructure is performing on a real-time basis. DFM also helps ensure data availability and business continuance by allowing administrators to proactively predict and protect against increased demand for storage and data resources through the use of quotas, threshold settings, and the prepositioning of data.
In one embodiment, the manager server 10 allows a user to manage all of the data replication relationships (that is four relationships in the simplified example of
Providing a central management database for the data replication relationships implemented by the storage servers is highly convenient. In one embodiment, the storage servers can be configured to automatically report all relationships to the manager server 10, so that the manager server 10 can update the appropriate data structure.
In one embodiment, the manager server 10 allows a user to create replication policies and to use the data structure to apply a replication policy to each of the data replication relationships. An asynchronous replication policy can include a unique name for the policy, a throttle, and a replication schedule as described above. Such policies can include other attributes, such as an indicator whether an aborted update should restart, a lag-warning time, and a lag-error time. A synchronous policy can similarly have a name, and could indicate the amount of data allowed to be outstanding and the interval for which persistent consistency point images (PCPIs) of the source are created.
In one embodiment, the data structure storing the relationships in the manager server can be used by the manager server 10 to apply the policies created by the user to the data replication relationships. In other words, the data structure can be used to assign each relationship to a replication policy. For example, an entry in the data structure could be: “data source, data destination, replication policy name.” For example, a table data structure representing the relationships described in the example of
TABLE 1
Data Source
Data Destination
Policy Name
4(a)
5(c)
Dbase Policy
4(c)
9(b)
Dbase Policy
5(b)
4(b)
Every-Hour Policy
9(a)
5(a)
Every-Hour Policy
If a user wished to change the update schedule (or some other attribute) of a group of relationships encompassed by a policy, the user only needs to change the policy, which is then automatically applied by the manager server 10 to all data replication relationships associated with the policy. In one embodiment, any policy changes are also automatically propagated from the manager server 10 to the configuration files of the appropriate storage servers.
To further illustrate policy usage, data source 4(a) and 4(c) can be two volumes representing one database. Under the example policy shown in Table 1, the entire database is replicated once a day by the Dbase Policy. The user of the example system described with reference to
The processor 21 is the central processing unit (CPU) of the server 20 and, thus, controls the overall operation of the server 20. In certain embodiments, the processor 21 accomplishes this by executing software stored in main memory 22. The processor 21 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.
The main memory 22, which is generally some form of random access memory (RAM), stores the operating system 24 of the server 20. Techniques of the present invention may be implemented within the operating system 24, as described further below.
Also connected to the processor 21 through the bus system 23 are a network adapter 28 and a storage adapter 29. The network adapter 28 provides the server 20 with the ability to communicate with remote devices, such as clients and/or another storage or manager server, over a network and may be, for example, an Ethernet adapter. The storage adapter 29 allows the filer to access the external mass storage devices and may be, for example, a Fibre Channel adapter or SCSI adapter.
Above the file system 31, the operating system 24 also includes a user interface 33, through which a network administrator or other user can control and/or configure the filer (e.g., remotely from a management station). The user interface 33 may generate a command line interface and/or a graphical user interface for this purpose.
Below the file system 31, on the client side the operating system 24 includes a network layer 34 and, at the lowest level, a media access layer 35. The network access layer 34 implements any of various protocols used to communicate with client devices, such as network file system (NFS), common Internet file system (CIFS) and/or hypertext transport protocol (HTTP). The media access layer 35 includes one or more drivers which implemented the protocols used to communicate over the network, such as Ethernet.
Below the file system 31 on the storage device side, the operating system 24 includes a storage access layer 36 and, at the lowest level, a driver layer 37. The storage access layer 36 implements a disk storage protocol such as RAID, while the driver layer 37 implements a lower-level storage device access protocol, such as Fibre Channel or SCSI.
The operating system of 24 also includes a data replication module 32, which is operatively coupled to the file system 31 and the storage access layer 36. The data replication module 32 controls the synchronization of data at the remote secondary site with data stored at the primary site. The techniques introduced herein may be implemented at least partially within the data replication module 32.
With the thorough understanding of storage servers and centrally managing data replication relationships using replication policies provided by the descriptions above, various embodiments for system initialization are now set forth with reference to
In one embodiment shown in
In block 506, the manager server checks whether there already is an existing replication policy with the attributes of the relationship found in block 504. In one embodiment, all attributes must match (e.g., not just update schedule, but also throttle and other attributes) exactly to an existing policy. If such a policy is found, it is applied, in block 510, to the relationship found in block 504. In one embodiment, this includes storing the data source and data destination of the relationship in a data structure similar to Table 1, and associating the matching policy with the new entry.
If, on the other hand, a matching policy is not found, then in block 508, a replication policy having the attributes of the relationship found in block 504 is created. In one embodiment, since this policy is a new and unique policy, the policy is given a unique name, i.e., a name different from the names of all other policies. In block 510, this newly created policy is applied, by entry into the data structure shown in Table 1, to the relationship found in block 504. Blocks 504 to 510 are repeated until all data replication relationships implemented by the storage servers attached to the network have been entered into the central data structure with an associated replication policy.
After this initial network scan and central management data structure establishment, a user can edit the policies at the management server, or the individual relationships at both the central management server and at the individual storage servers. In one embodiment, the manager server implements a monitor thread to keep the central data structure up to date. For example, if a policy is edited, the monitor thread ensures that the new replication attributes are propagated to each individual storage server affected by the change, that is, each storage server implementing a relationship associated with the edited policy. Similarly, the editing of a data source and/or destination in the central data structure is also propagated to the appropriate storage servers.
In one embodiment, the monitor thread also detects edits and changes in the relationships across the storage servers, and updates the central data structure of the manager server accordingly. For example, if the update schedule of a data replication relationship is changed in a storage server connected to the network, then the monitor thread can perform blocks 506 to 510 in
To make replication policies easier to create, the user interface described above can provide the user of the system with a policy-cloning tool. In one embodiment, a graphical user interface (GUI) is provided to enable the user to author and edit policies (this feature may be referred to as the policy editor), and to enable the user to view the central data structure and to apply the policies to the data replication relationships contained therein (this feature may be referred to as the relationship manager). The policy editor feature can allow a user to configure each attribute of a replication policy. A policy-cloning tool can enable the user to select a policy, and create a clone, i.e., copy, of the policy.
In one embodiment, the cloned policy has identical attributes to the originally selected policy, except it has a unique, and hence different, name. For example, the world “cloned” or “copy of” can be added to the name of the original policy, if such addition would make the name of the new policy unique. The user can then use the policy editor to change certain attributes and the relationship manager to associate certain relationships with the newly cloned policy.
The techniques introduced above have been described in the context of a NAS environment. However, these techniques can also be applied in various other contexts. For example, the techniques introduced above can be applied in a storage area network (SAN) environment. A SAN is a highly efficient network of interconnected, shared storage devices. One difference between NAS and SAN is that in a SAN, the storage server (which may be an appliance) provides a remote host with block-level access to stored data, whereas in a NAS configuration, the storage server provides clients with file-level access to stored data. Thus, the techniques introduced above are not limited to use in a file server or in a NAS environment.
Thus, a method and apparatus for a manager server configured to centrally manage data replication relationships have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
Patent | Priority | Assignee | Title |
10037348, | Apr 08 2013 | NUODB, INC | Database management system with database hibernation and bursting |
10067969, | May 29 2015 | Nuodb, Inc.; NUODB, INC | Table partitioning within distributed database systems |
10110667, | Apr 08 2008 | RPS CANADA INC | System and method for providing data and application continuity in a computer system |
10133511, | Sep 12 2014 | NetApp, Inc | Optimized segment cleaning technique |
10135922, | Aug 29 2014 | NetApp Inc. | Granular sync/semi-sync architecture |
10180954, | May 29 2015 | Nuodb, Inc.; NUODB, INC | Disconnected operation within distributed database systems |
10210082, | Sep 12 2014 | NetApp, Inc. | Rate matching technique for balancing segment cleaning and I/O workload |
10282247, | Mar 15 2013 | Nuodb, Inc. | Distributed database management system with node failure detection |
10365838, | Nov 18 2014 | NetApp, Inc. | N-way merge technique for updating volume metadata in a storage I/O stack |
10565230, | Jul 31 2015 | NetApp, Inc.; NetApp, Inc | Technique for preserving efficiency for replication between clusters of a network |
10740323, | Mar 15 2013 | NUODB, INC | Global uniqueness checking in distributed databases |
10769174, | May 31 2018 | KYNDRYL, INC | Site-consolidated disaster-recovery with synchronous-to-asynchronous traffic conversion |
10776394, | May 31 2018 | KYNDRYL, INC | Synchronous site-consolidated data backup with synchronous-to-asynchronous traffic conversion |
10802868, | Jan 02 2020 | International Business Machines Corporation | Management of transactions from a source node to a target node through intermediary nodes in a replication environment |
10880235, | Aug 20 2009 | Oracle International Corporation | Remote shared server peripherals over an ethernet network for resource virtualization |
10884869, | Apr 16 2015 | Nuodb, Inc.; NUODB, INC | Backup and restore in a distributed database utilizing consistent database snapshots |
10911328, | Dec 27 2011 | NetApp, Inc. | Quality of service policy based load adaption |
10929022, | Apr 25 2016 | NetApp. Inc. | Space savings reporting for storage system supporting snapshot and clones |
10951488, | Dec 27 2011 | NetApp, Inc. | Rule-based performance class access management for storage cluster performance guarantees |
10997098, | Sep 20 2016 | NetApp, Inc | Quality of service policy sets |
11016956, | Apr 08 2013 | Nuodb, Inc. | Database management system with database hibernation and bursting |
11070612, | Apr 08 2008 | RPS CANADA INC | System and method for providing data and application continuity in a computer system |
11176111, | Mar 15 2013 | Nuodb, Inc. | Distributed database management system with dynamically split B-tree indexes |
11212196, | Dec 27 2011 | NetApp, Inc. | Proportional quality of service based on client impact on an overload condition |
11222008, | May 29 2015 | Nuodb, Inc. | Disconnected operation within distributed database systems |
11301490, | May 31 2018 | KYNDRYL, INC | Synchronous database replication with asynchronous transaction recovery |
11314714, | May 29 2015 | Nuodb, Inc. | Table partitioning within distributed database systems |
11327910, | Sep 20 2016 | NetApp, Inc | Quality of service policy sets |
11379119, | Mar 05 2010 | NetApp, Inc. | Writing data in a distributed data storage system |
11386120, | Feb 21 2014 | NetApp, Inc. | Data syncing in a distributed system |
11561961, | Mar 15 2013 | Nuodb, Inc. | Global uniqueness checking in distributed databases |
11573940, | Aug 15 2017 | NUODB, INC | Index splitting in distributed databases |
11575736, | Apr 08 2008 | RPS CANADA INC | System and method for providing data and application continuity in a computer system |
11748206, | Aug 28 2019 | International Business Machines Corporation | Data recovery modification based on performance data exhibited by a network of data centers and data recovery requirement |
11886363, | Sep 20 2016 | NetApp, Inc. | Quality of service policy sets |
8019839, | May 11 2009 | Accenture Global Services Limited | Enhanced network adapter framework |
8224860, | Mar 18 2010 | NUODB, INC | Database management system |
8504523, | Mar 18 2010 | NuoDb Inc. | Database management system |
8533302, | May 11 2009 | Accenture Global Services Limited | Enhanced network adapter framework |
9015290, | May 11 2009 | Accenture Global Services Limited | Enhanced network adapter framework |
9015291, | May 11 2009 | Accenture Global Services Limited | Enhanced network adapter framework |
9021142, | Jul 20 2006 | Oracle America, Inc. | Reflecting bandwidth and priority in network attached storage I/O |
9311374, | Nov 30 2010 | Red Hat, Inc.; Red Hat, Inc | Replicating data objects within a storage network based on resource attributes |
9331963, | Sep 24 2010 | Oracle International Corporation | Wireless host I/O using virtualized I/O controllers |
9501363, | Mar 15 2013 | Nuodb, Inc. | Distributed database management system with node failure detection |
9571575, | Aug 29 2014 | NetApp, Inc | Granular sync/semi-sync architecture |
9671960, | Sep 12 2014 | NetApp, Inc.; NetApp, Inc | Rate matching technique for balancing segment cleaning and I/O workload |
9674268, | Apr 08 2008 | RPS CANADA INC | System and method for providing data and application continuity in a computer system |
9710317, | Mar 30 2015 | NetApp, Inc. | Methods to identify, handle and recover from suspect SSDS in a clustered flash array |
9720601, | Feb 11 2015 | NetApp, Inc. | Load balancing technique for a storage array |
9740566, | Jul 31 2015 | NetApp, Inc.; NetApp, Inc | Snapshot creation workflow |
9762460, | Mar 24 2015 | NetApp, Inc | Providing continuous context for operational information of a storage system |
9798728, | Jul 24 2014 | NetApp, Inc. | System performing data deduplication using a dense tree data structure |
9805104, | Feb 15 2013 | Microsoft Technology Licensing, LLC | Recovery point objective enforcement |
9813283, | Aug 09 2005 | Oracle International Corporation | Efficient data transfer between servers and remote peripherals |
9836229, | Nov 18 2014 | NetApp, Inc. | N-way merge technique for updating volume metadata in a storage I/O stack |
9848043, | Aug 29 2014 | NetApp, Inc. | Granular sync/semi-sync architecture |
9860310, | Apr 08 2008 | RPS CANADA INC | System and method for providing data and application continuity in a computer system |
9973446, | Aug 20 2009 | Oracle International Corporation | Remote shared server peripherals over an Ethernet network for resource virtualization |
Patent | Priority | Assignee | Title |
6839746, | Jun 03 2003 | Veritas Technologies LLC | Storage area network (SAN) device logical relationships manager |
6950871, | Jun 29 2000 | Hitachi, LTD | Computer system having a storage area network and method of handling data in the computer system |
20040093555, | |||
20040098419, | |||
20050010529, | |||
20050120025, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Mar 12 2004 | NetApp, Inc. | (assignment on the face of the patent) | / | |||
Jul 27 2004 | FONG, YINFUNG | Network Appliance, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014922 | /0627 | |
Jul 28 2004 | LAM, SAHN | Network Appliance, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014922 | /0627 | |
Mar 10 2008 | Network Appliance, Inc | NetApp, Inc | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 066870 | /0865 |
Date | Maintenance Fee Events |
Jan 03 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 01 2016 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jan 02 2020 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Jul 01 2011 | 4 years fee payment window open |
Jan 01 2012 | 6 months grace period start (w surcharge) |
Jul 01 2012 | patent expiry (for year 4) |
Jul 01 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jul 01 2015 | 8 years fee payment window open |
Jan 01 2016 | 6 months grace period start (w surcharge) |
Jul 01 2016 | patent expiry (for year 8) |
Jul 01 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jul 01 2019 | 12 years fee payment window open |
Jan 01 2020 | 6 months grace period start (w surcharge) |
Jul 01 2020 | patent expiry (for year 12) |
Jul 01 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |